Presentation article rest : How-to
2 j'aime1,064 vues
Le document présente les principes fondamentaux de l'architecture REST, en mettant l'accent sur des contraintes telles que l'identification des ressources et l'auto-description des messages. Il discute également des divergences entre REST et SOAP, des défis liés à la négociation de format et de l'importance de la documentation et du versionnage des services. Enfin, il évalue différents frameworks basés sur leurs performances et leur conformité aux principes REST.
![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]](https://image.slidesharecdn.com/presentationarticlerest-121213093625-phpapp01/85/Presentation-article-rest-How-to-3-320.jpg)
![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]](https://image.slidesharecdn.com/presentationarticlerest-121213093625-phpapp01/85/Presentation-article-rest-How-to-5-320.jpg)
![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]](https://image.slidesharecdn.com/presentationarticlerest-121213093625-phpapp01/85/Presentation-article-rest-How-to-21-320.jpg)
Presentation article rest : How-to
- 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