Pour bien commencer avec les Architectures REST ou RESTFUL

La vague  REST va déferler sur nous. Hélas, la encore des marchands de rêve vont chercher à vous vendre du REST au kilo.

Ce qu'il faut bien  comprendre: Les architectures REST devront être une CONSÉQUENCE de l'évolution de vos applications  et non pas une CAUSE d'évolution de celles-ci.
En clair: commencer par mette du REST sans avoir ce qui va avec, mettra en difficulté votre système informatique, vos équipes etc.

Pour commencer le REST (ou RESTFUl ) c'est quoi ?

• C'est une une  thèse de Roy T. Fielding. En 2000.

«Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000.»

Un chapitre ici traduit en français. (Le 5eme : un des plus important)

• C'est un livre de chevet (publié en 2007) :lien ici 

Couverture ( observez qui à donné son avis sur le livre)

(selfie truqué : pourquoi ? : à vous de trouver l'erreur)

• C'est une série de principe : 

1) Utilisation des verbes (Méthodes) du HTTP.
GET : lire une ressource
DELETE : supprimer une ressource
POST et PUT: pour creer ou modifier une ressource
(ou inversement : l'idée est d avoir un verbe pour créer différent de celui utiliser pour modifier)

source stackoverflow: http://stackoverflow.com/questions/630453/put-vs-post-in-rest

2) Chaque ressource a son URL. On interagit avec les ressources en combinant les  url avec les methodes HTTP.

• GET http://www.example.com/customers/12345
• GET http://www.example.com/customers/12345/orders
• GET http://www.example.com/buckets/sample
• PUT http://www.example.com/customers/12345
• PUT http://www.example.com/customers/12345/orders/98765

3) Pas de session gérée  coté serveur : Toute l'information de session est stockée sur le client ET donc chaque requête est autonome et complète.

4) Le serveur applicatif ne sert qu'a délivrer de la donnée (le plus souvent au format JSON et non plus XML)

Voila le rapidement présenté le  REST.

Pourquoi le REST a-t-il le vent en poupe ?

• Il permet de répartir les coûts d'infrastructure entre le fournisseur de ressource (service) et l'utilisateur (poste client). Il est donc pleinement compatible avec le modèle économique des clouds. Les traitements coûteux en CPU  (assemblages des pages WEB, manipulation des donnée)  sont réalisés sur la machine du client. 

• Les infrastructures et les applications sont plus simples: pas besoin d'avoir des serveurs de session, des bus d'entreprise etc. 

• La scalabilité est linéaire: sans partage de session à prévoir, avec des serveurs à gestion d 'événement (Node.js , nginx) , l'ajout d'un serveur augmente surement le nombre de connexion possible.

• Il met fin au débat entre les langages et les framework : PHP ,Java, Spring, Express, Rails  :La partie serveur ne sert qu'a délivrer de la donnée JSON. Le seul langage à maîtriser vraiment est le Javascript (le seul langage universel pour le navigateurs). Aussi, si vous n'avez pas les ressources de développement aguerries au Javascript l'adoption du  REST sera difficile.

Aussi mettre en place du REST sans avoir un idée de la stratégie à mettre en place coté client (Angular, Backbone , Ember ?...) c'est prendre le sujet à l'envers.

Comment reconnaître le vrai du faux REST.

Le critère de la session gérée coté client est important, sinon le simple test suivant est suffisant :

Est ce que votre application fonctionne avec le simple client HTTP en ligne de  commande CURL ?

Ex :  curl -X DELETE http://localhost:4567/pgm/5352d84751514034cc000048

(la partie serveur qui répond à la requete)

## Restful uri

##
delete '/pgm/:id'  do
@id_pgm =  params[:id]
@pgm =  @db['pgm'].remove('_id'  => BSON::ObjectId(@id_pgm) )
response.write ("{ok}")
end