You will find on this website publications about informations technologies. The content is available in french and english.

mercredi, 1 novembre 2006

REST : a scalable architecture

During architecture definition, we have to choose what will be the differents concepts and principes.
They can be evaluated in a qualitative manner with differents aspects, but a “validating” major aspect is the scalability, that‘s to say : does the built system can handle an important load without major redesign ?
Scalability with computer can be get notably with a non exponential use of resources as one goes along the load increase. The reducing of the system generated states is one of the answer to this problem. That‘s why the functional languages are interesting, but it will be the subject of another post.

So considerated, the REST (Representational State Transfer) architectural style answer quite well to this challenge. This architectural style is the web one. This style is based on the stateless protocol HTTP that offer four "verbs" GET, POST, PUT and DELETE on resources Theses verbs are very close to the CRUD well known in database. Each one represent a particular action that modify or not the system state. Then :

  • GET : this action is idempotent et does not modify the system state. It is similar to a data read.
  • POST : modify the system state and is not idempotent, example: adding an item to a basket or the validation of the basket. These datas aren‘t part of the URI.
  • PUT : create or modify a particular resource but is idempotent.
  • DELETE : delete a resource.

REST was initialy proposed by Roy Thomas Fielding as his PhD's thesis .
So REST is an architectural style that is simple and very robust, validated by the web experience and that can be combined to the power of the XML language. This post was inspired to me by those of Eliotte Rusty-Harold that ask some questions of practical interest very interesting about REST and the use of the HTTP protocol.

The REST style is effectively simple, but is it sufficient to build complex interactions and avoid to move a major part of the applicative logic onto the client ?
A very interesting example is given by this article that provide a REST translation of a mail service, this example illustrate all the importance of correct resources identification. The parallel with the object approach is also decided concerning the resource representation.

Some links to go forward on REST :

Technorati Tags:

Posted at 10:54 PM in en/Architecture/
portage salarial freelance