Presentation de l'article universitaire :
REST How-to
Un guide pour une architecture REST.
Les questions qu'il est nécessaire de se poser pour établir un cahier des charges efficace et éviter les pièges de SOAP.
10 Décembre 2012 UQAC ISEN
3. REST met l'accent sur :
● Extensibilité des interactions entre composants
● Généralité des interfaces
● Déploiement indépendant des composants
● L'utilisation de composant intermédiaires pour résoudre les
problèmes de performances, de sécurité ou encapsuler un
système
Pourquoi REST ? [Fielding]
5. REST arrive à ses fins par quatre contraintes:
● Identification des ressources
● Manipulation des ressources par des représentations
● Messages auto-décrits
● Hypermedia en tant que machine d'état
REST en 4 contraintes [Paul Prescod]
6. Prendre un bon départ
Pour éviter les erreurs de SOAP, il faut
analyser les divergences au sein de REST
12. Négociation du format
Le format des messages est décrit avec les
Headers HTTPs:
● Accept-Type
● Content-Type
Problème : certains composants ne les
supportent pas.
C'est pénible pour tester dans un navigateur.
Pragmatiques : /users/124.{format}
13. Negocier le format
avec les headers
Autoriser le format dans l'extension
14. Découverte et Hypermedia
Il n'y a pas de description de service.
Le service doit être découvert.
Pour cela, on utilise Hypermedia (liens
Hypertextes).
18. Versions et dynamisme
Un service doit pouvoir évoluer dynamiquement
sans déprécier ses consommateurs.
Problème : Les clients ne découvrent pas le
service.
Solution : versionner le service
21. Le XML (Extensible Markup Language, « langage
de balisage extensible ») est un langage
informatique de balisage générique qui dérive du
SGML. Cette syntaxe est dite extensible car elle
permet de définir différents espaces de noms,
c'est-à-dire des langages avec chacun leur
vocabulaire et leur grammaire, comme XHTML,
XSLT,RSS, SVG…
XML [Wikipedia]
22. Un message XML doit
préciser son Schema
Au format XML Schema
23. Synthèse
● Supporter les 4 verbes HTTPs
○ Mais proposer une alternative uniforme
● Utiliser les codes HTTPs
○ Mais permettre de forcer le code 200
● Negocier le type dans les headers HTTPs
○ Autoriser le type dans l'extension
● Offir une documentation HTML orientée ressource
○ Lisible par un humain, découvrable par un robot
● Versionner un service par ses routes
○ Pour ne jamais déprécier une route
● XML doit préciser son schema
○ XML Schema est fait pour ça
24. L'Homogénéité d'abord !
Java DotNet
● Play! ● MVC4 Web API
● Jersey (JAX-RS) ● WCF REST Template
● RestLet
Ruby Python
● Ruby On Rails ● Flask
● Sinatra ● Bottle
PHP ● Web.py
● Symphony ● MimeRender
26. Nom du Framework Rails Play! RestLet
Négociation du Format 5/5 4/1 5/3
(Header/.{format})
HiRest / LowRest 5/5 5/3 5/2
Respect du Stateless 5 5 5
Format JSON / XML 5/5 3/4 5/4
CLOC (vide / une 391 / 498 40 / 432 (hors XML) 56 / 183
ressource)
Temps développement 15 minutes 20 min 20 minutes
pour une ressource
Courbe d'apprentissage Exponentielle Logarithmique Echelon
Support IDE / 4/4 3/2 4/4
Experience
Caractéristiques de quelques frameworks
Légende : 5 = natif dans le framework - 0 = presque impossible à implémenter
27. Concurrence Rails Play! Restlet (GAE)
(Heroku/Thin) (Heroku)
Requêtes Par 100 85.95 230.25 144.84 (3-2)
Seconde
moyen (#/s) 1000 197.62 220.33 (3-2)
Temps Par 100 11.634 4.343 6.904 (5-3)
Requête moyen
(ms) 1000 5.060 4.539 (5-3)
Performances : Apache Benchmark
28. Références
1. "Architectural Styles and the Design of Network-based Software
Architectures", Thèse, Roy Thomas Fielding, 2000, http://www.ics.uci.
edu/~fielding/pubs/dissertation/rest_arch_style.htm
2. “Roots of the SOAP/REST Debate”, Paul Prescod, 2002
3. “How Restful is your API”, Cori House, 2012 http://www.bitnative.
com/2012/08/26/how-restful-is-your-api/
4. "Richardson Maturity Model, steps toward the glory of REST", Martin
Fowler, 2010
5. "Distributed Systems, Concepts And Design", 5th edition, Coulouris et al,
2012