| This proposal is being split into two: one for Zend\Rest\Client and another for Zend\Rest\Server |
- Overview
- References
- Component Requirements, Constraints, and Acceptance Criteria
- Theory of Operation
- Dependencies on Other Framework Components
- Milestones / Tasks
- Class Index
- Use Cases
- UC-01 Simple GET request
- UC-02 Creating a new resource using PUT
- UC-03 Updating an existing resource
- UC-04 Deleting an existing resource
- UC-05 Detecting hypermedia
- UC-06 Providing a custom content type negotiator for parsing custom responses (e.g. YAML).
- UC-07 Conditional GET with Zend\Cache
- Class Skeletons
Overview
The REST client in ZF 1.x only supports XML content types. Since REST does not dictate which content type to respond with, some REST services opt to use other formats such as JSON. Additionally, the REST client can benefit from supporting hypermedia to help make services self-discoverable.
Changes to Zend_Rest_Client
Zend\Rest\Client will be updated to support various content return types, including custom ones that were not anticipated during this proposal. Optionally a hypermedia parser can help to discover hypermedia within the returned content body.
References
Component Requirements, Constraints, and Acceptance Criteria
- This component will introduce BC breaks with ZF 1.x.
- This component will support content type negotiation with built in support for XML, JSON and ATOM.
- This component will use a LIFO stack for negotiation prioritization.
- This component will support custom content types.
- This component may parse responses for HyperMedia.
- This component will support custom HyperMedia parsers.
- This component will understand ETags.
- This component may support client-side caching (e.g. to support conditional GET).
- This component may use CRUD as aliases for HTTP verbs.
Theory of Operation
The client should be easy to use. In its simplest form:
Dependencies on Other Framework Components
- Zend\Service\AbstractService
- Zend\Http\Client
- Zend\Uri
Milestones / Tasks
- Milestone 1: Acquire community acceptance of proposal
- Milestone 2: Working prototype checked in to github fork
- Milestone 3: Unit tests checked in to github fork
- Milestone 4: Acquire community acceptance of github fork
- Milestone 5: Submit pull request to zf2
Class Index
- Zend\Rest\Client\RestClient
- Zend\Rest\Client\Response\ResponseInterface
- Zend\Rest\Client\Response\Response
- Zend\Rest\Client\Negotiator\NegotiatorInterface
- Zend\Rest\Client\Negotiator\Xml
- Zend\Rest\Client\Negotiator\Json
- Zend\Rest\Client\Negotiator\Atom
Use Cases
UC-01 Simple GET request
UC-02 Creating a new resource using PUT
UC-03 Updating an existing resource
UC-04 Deleting an existing resource
UC-05 Detecting hypermedia
UC-06 Providing a custom content type negotiator for parsing custom responses (e.g. YAML).
UC-07 Conditional GET with Zend\Cache
Class Skeletons
Labels:
None
2 Comments
comments.show.hideFeb 06, 2012
Tim Fountain
(duplicate)
Feb 06, 2012
Tim Fountain
Any changes to the way Zend_Rest_Client handles params (specifically multiple GET params)? I know this has caused some issues (see the warning in the manual and #ZF-9307 as examples). Personally I'd prefer to see a syntax more along the lines of: