REST (Representational State Transfer) in PHP is still in its infancy, and to my knowledge there are no PHP frameworks that make working with REST easy. I’d like to see Ismo be able to handle REST concepts (the very basics are already there) natively and cleanly.
Things we’ll need to consider are:
Various
HTTP requests beyond GET and POST (ex., DELETE, PUT)
Making the
URL the central skeleton of the application
perhaps build the basics of the Applicaiton from a
URL “schema”?
The following bullet points are from a review by Matthew Turland of the Recess! Framework:
Modification of the application response to indicate to the client that the response data can be cached and for how long. This reduces demands on the server because the client can used the cached response for a time rather than having to request it from the server again. Server-side caching has its place but the less traffic that the server has to handle, the better.
Support for multiple representations of each resource. Ideally, all resources should have a unique canonical
URL from which they can always be accessed and their representation format determined using content negotiation. This includes the content format (
HTML,
XML, JSON, Atom, etc.), language (English, French, Spanish, etc.), and character set (
ISO-8859-1, UTF-8, etc.). So long as this is maintained, it is acceptable to also offer other URLs specific to particular representations of a given resource. (Twitter does this.)
Declaration of which methods (GET, HEAD, POST, PUT, DELETE) each offered resource supports, as not all resources may support all methods, and a mechanism to return an appropriate
HTTP response (405 Method Not Allowed) if a resource is accessed using an unsupported method. Responses should include an Allow header indicating supported methods, especially in 405 responses but ideally for HEAD requests as well.
Support for documentation generation from REST service source code. Ideally, this would come in the form of a service browser that offered full explanations of each resource including available representations and methods, possibly with WSDL 2.0 support.
Content encoding (gzip, deflate) should be supported in both directions. That is, a client should be able to submit data that is encoded and the server should be able to encode content when the client requests it.
This is a minimized, in-progress “checklist” version of the above for easy reference: * define resources * define supported methods * send proper HTTP error messages * send informative Allow header (with 405’s and HEAD requests especially)
(optional, but nice) * documentation
See also:
