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

1. REST How-to
Presentation d'article
Damien Cavaillès - 14/12/12 - UQAC

2. Introduction
REST :
● Qui?
● Quand?
● Pourquoi?

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]

4. Contribution
REST, comment?
Quelles exigences pour ne pas répéter les
erreurs de SOAP?
Quelles solutions? A quel coût?

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

7. RESTafarian vs Pragmatiques : les bonnes questions

8. Les verbes HTTPs
HiREST : 4 verbes
LoREST : 2 verbes
/users/124?method=delete

9. Supporter les 4 verbes
Supporter une alternative : paramètre GET
"method"

10. Les Codes HTTPs
Il existe 71 codes HTTPs.
Certains clients ne supportent pas d'autres
codes que le 200 (Flash ...).

11. Utiliser les codes HTTPs
Mais permettre de forcer le code 200

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).

15. Découverte et Hypermedia
Problème :
JSON et XML, ne sont pas Hypermedia.
Ils n'embarquent pas nativement de liens Href.

16. Solution répandue : publier une liste des routes
C'est un WSDL pour les humains, avec du HTML/CSS

17. Offrir une documentation
orientée ressource
Découvrable par un robot
Lisible par un humain

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

19. Versionner un service par
ses routes
https://entrypoint/version_number/...

20. XML
Message auto-décrits !
XML n'est pas un format.

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

25. Expérimentation
● Evaluer le bootstrapping
● Evaluer l'experience developpeur
● Mesurer les performances

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