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
(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 |
- 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
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
## Restful uri
##
delete '/pgm/:id' do
@id_pgm = params[:id]
@pgm = @db['pgm'].remove('_id' => BSON::ObjectId(@id_pgm) )
response.write ("{ok}")
end
