REST in peace
Within the descriptions of REST as an architectural style, every information or resource is supposed to be identifiable by a resource identifier or URI. Components in a RESTful environment can apply actions on resources according to their representational state. A webbrowser for example issues a request for a particular URI and retrieves the current state of the resource in xhtml. The browser is then capable of rendering the representation into a colorful webpage.
According to a purist view on REST, the distinctiveness of an URI implies its persistence independent of the action applied to it (/fileinfo/delete/myfile.txt and /fileinfo/add/myfile.txt are two different uris for the same resource). Moreover, REST relies on HTTP with its variety of request methods and it is not counted to be RESTful, if all actions have to be performed via GET. Besides the argument of not using HTTP the way it should be, there are also reasons from the view of the implementation that i find more convincing: Parameters are a source for errors, lead to ambigous requests, have to be caught and evaluated etc.
The specifications suggest a mapping of HTTP request methods that refer to particular functions:
The perfect world is nice. However, in practice one hardly finds anything beyond GET and POST methods in relation to REST apis. GET for read-only requests and POST often combines requests to either create or update a resource. An interesting option would be to include reflection mechanisms into HEAD requests. Especially since REST doesn't has something likethe unnecessary complicated WSDL to describe a service. The ways to define REST apis seem to be quite versatile. Yahoo for example defines a single resource for the websearch api. Further adjustements on the result representation are all applicable via parameters.
References / more:
According to a purist view on REST, the distinctiveness of an URI implies its persistence independent of the action applied to it (/fileinfo/delete/myfile.txt and /fileinfo/add/myfile.txt are two different uris for the same resource). Moreover, REST relies on HTTP with its variety of request methods and it is not counted to be RESTful, if all actions have to be performed via GET. Besides the argument of not using HTTP the way it should be, there are also reasons from the view of the implementation that i find more convincing: Parameters are a source for errors, lead to ambigous requests, have to be caught and evaluated etc.
The specifications suggest a mapping of HTTP request methods that refer to particular functions:
| Method | Operation | |
| GET | retrieve | retrieves the representaiton of a resource |
| HEAD | retrieves metadata for the representation and the resource |
|
| POST | create | creates a resource |
| PUT | update | updates a resource |
| DELETE | delete | deletes a resource |
The perfect world is nice. However, in practice one hardly finds anything beyond GET and POST methods in relation to REST apis. GET for read-only requests and POST often combines requests to either create or update a resource. An interesting option would be to include reflection mechanisms into HEAD requests. Especially since REST doesn't has something like
References / more:
- Roy Thomas Fielding - Architectural Styles and the Design of Network-based Software Architectures
- Robert Richards - Pro PHP XML and Web Services
- Yahoo! Search APIs
