Felines With Blood Coming Out The Ear

Rest - Part 2

In the previous post we established that is left is basically a set of constraints on communication for some benefits. We see in detail what are these constraints and what the benefits with an approach a bit 'more down to earth than that of Fielding's work, but first let's step back to the definition.

Representational State Transfer, freely translated as "transfer of representations of the state" ... Is not something missing? State of what? Was a Resource! This is the first and biggest stumbling block facing Rest of speaking: communication between components is not seen as the invocation of methods on remote objects (RPC remote procedure call), but as access to state of a resource. If you are extracting javistica like me, you'll be already ringing alarm bells: "Access to state ? But the state must be encapsulated and hidden." Well no, at least not if the approach remains married.

over the shock of this discovery, we return to the rules of the game to fulfill in order to say Restful.

1. Unique identification of resources
2. uniform interface to access the representation
3. Negotiation between client and server
4. Hypertext as the engine of the state

These so sound a bit 'abstract. Smontiamole calandole one by one on the reality of the HTTP protocol, which is the embodiment of theories remain most popular.


Unique identification of resources
Each resource must be addressed by a unique pointer. Must have its own key, a URL address ... one that identifies her. His "handle" to manipulate it. Warning: This identifier must be a pointer, bees should not be a manipulation in itself! Let me explain: how many times we happened to write something like

http://xyz/foo/bar?action insert = & item = abc

Well, in this case the pointer to the resource (the url) is "overloaded" with the semantics of behavior. Basically you are not "appointed" a resource by its URL, you're already describing an action on the resource itself.

uniform interface to access

We know how to refer to a resource by its URL. We therefore object on which to perform the operations but ... we lack the operations. What we can do with an object? A Javista would say "depends on its interface, or by the methods that the object exposes. The REST approach requires a uniform interface for handling all the resources. For example, the HTTP protocol provides that on each resource can be a defined set of tasks, always the same regardless of the resource. These actions are mapped (with some small burrs) on the CRUD functionality

CREATE POST or PUT

GET READ

UPDATE, DELETE, PUT, DELETE

Taking the example above, use Restful HTTP protocol provides for the creation of a resource is "modeled" as a GET parameter in the URL with insert, but rather as a PUT to the URL you want

GET http://xyz/foo/ bar? action = insert & item = abc NO!

http://xyz/foo/bar/abc PUT IT!