This shows you the differences between the selected revision and the current version of the page.
| ideas:rest_focus 2008/11/14 15:08 | ideas:rest_focus 2009/03/05 08:49 current | ||
|---|---|---|---|
| Line 8: | Line 8: | ||
| * perhaps build the basics of the Applicaiton from a URL "schema"? | * perhaps build the basics of the Applicaiton from a URL "schema"? | ||
| + | ==== REST Framework Essentials ==== | ||
| + | The following bullet points are from a [[http://blueparabola.com/blog/rest-recess-framework|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:** | **See also:** | ||