Presentation article rest : How-to

1,141 views

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,141
On SlideShare
0
From Embeds
0
Number of Embeds
163
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Presentation article rest : How-to

  1. 1. REST How-to Presentation darticleDamien Cavaillès - 14/12/12 - UQAC
  2. 2. IntroductionREST :● Qui?● Quand?● Pourquoi?
  3. 3. REST met laccent sur :● Extensibilité des interactions entre composants● Généralité des interfaces● Déploiement indépendant des composants● Lutilisation de composant intermédiaires pour résoudre les problèmes de performances, de sécurité ou encapsuler un système Pourquoi REST ? [Fielding]
  4. 4. ContributionREST, comment?Quelles exigences pour ne pas répéter leserreurs de SOAP?Quelles solutions? A quel coût?
  5. 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. 6. Prendre un bon départPour éviter les erreurs de SOAP, il fautanalyser les divergences au sein de REST
  7. 7. RESTafarian vs Pragmatiques : les bonnes questions
  8. 8. Les verbes HTTPsHiREST : 4 verbesLoREST : 2 verbes /users/124?method=delete
  9. 9. Supporter les 4 verbesSupporter une alternative : paramètre GET "method"
  10. 10. Les Codes HTTPsIl existe 71 codes HTTPs.Certains clients ne supportent pas dautrescodes que le 200 (Flash ...).
  11. 11. Utiliser les codes HTTPs Mais permettre de forcer le code 200
  12. 12. Négociation du formatLe format des messages est décrit avec lesHeaders HTTPs:● Accept-Type● Content-TypeProblème : certains composants ne lessupportent pas.Cest pénible pour tester dans un navigateur.Pragmatiques : /users/124.{format}
  13. 13. Negocier le format avec les headersAutoriser le format dans lextension
  14. 14. Découverte et HypermediaIl ny a pas de description de service.Le service doit être découvert.Pour cela, on utilise Hypermedia (liensHypertextes).
  15. 15. Découverte et HypermediaProblème :JSON et XML, ne sont pas Hypermedia.Ils nembarquent pas nativement de liens Href.
  16. 16. Solution répandue : publier une liste des routesCest un WSDL pour les humains, avec du HTML/CSS
  17. 17. Offrir une documentation orientée ressource Découvrable par un robot Lisible par un humain
  18. 18. Versions et dynamismeUn service doit pouvoir évoluer dynamiquementsans déprécier ses consommateurs.Problème : Les clients ne découvrent pas leservice.Solution : versionner le service
  19. 19. Versionner un service par ses routes https://entrypoint/version_number/...
  20. 20. XMLMessage auto-décrits !XML nest pas un format.
  21. 21. Le XML (Extensible Markup Language, « langagede balisage extensible ») est un langageinformatique de balisage générique qui dérive duSGML. Cette syntaxe est dite extensible car ellepermet de définir différents espaces de noms,cest-à-dire des langages avec chacun leurvocabulaire et leur grammaire, comme XHTML,XSLT,RSS, SVG… XML [Wikipedia]
  22. 22. Un message XML doitpréciser son Schema Au format XML Schema
  23. 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 lextension● 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. 24. LHomogénéité dabord !Java DotNet● Play! ● MVC4 Web API● Jersey (JAX-RS) ● WCF REST Template● RestLetRuby Python● Ruby On Rails ● Flask● Sinatra ● BottlePHP ● Web.py● Symphony ● MimeRender
  25. 25. Expérimentation● Evaluer le bootstrapping● Evaluer lexperience developpeur● Mesurer les performances
  26. 26. Nom du Framework Rails Play! RestLetNégociation du Format 5/5 4/1 5/3(Header/.{format})HiRest / LowRest 5/5 5/3 5/2Respect du Stateless 5 5 5Format JSON / XML 5/5 3/4 5/4CLOC (vide / une 391 / 498 40 / 432 (hors XML) 56 / 183ressource)Temps développement 15 minutes 20 min 20 minutespour une ressourceCourbe dapprentissage Exponentielle Logarithmique EchelonSupport IDE / 4/4 3/2 4/4Experience Caractéristiques de quelques frameworks Légende : 5 = natif dans le framework - 0 = presque impossible à implémenter
  27. 27. Concurrence Rails Play! Restlet (GAE) (Heroku/Thin) (Heroku)Requêtes Par 100 85.95 230.25 144.84 (3-2)Secondemoyen (#/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. 28. Références1. "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.htm2. “Roots of the SOAP/REST Debate”, Paul Prescod, 20023. “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, 20105. "Distributed Systems, Concepts And Design", 5th edition, Coulouris et al, 2012

×