Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Restful, really ? MixIt 2014

1,255 views

Published on

Tout le monde dit faire ou vouloir faire une architecture de type Rest, que cela implique-t-il vraiment ?

Où vous situez-vous sur le "Richardson Maturity Model" ? Votre API est à la fois Hypermedia et JSON, « Are you kidding ? »

Si ce sont des questions qui vous taraudent l'esprit et même vous empêchent de dormir, alors venez écouter ce talk pour avoir des pistes de réflexions, des échanges et peut-être des réponses, qui sait ?

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Restful, really ? MixIt 2014

  1. 1. #Restful, really ? Faire une architecture de type Rest, que cela implique-t- il vraiment ? Xavier Carpentier Twitter: @xcapetir contact@xavier- carpentier.com
  2. 2. Définition • Representational State Transfer • Rest est un style d'architecture client / serveur, en couches avec une interface uniforme, utilisant le cache et étant stateless
  3. 3. Contexte & implication • Retour d'expérience développeur • d'API :communication avec partenaires • d'applications web et mobile qui utilisent des APIs • Arrêter de penser Remote Procedure Call
  4. 4. –Phil Karlton “There are only two hard things in Computer Science: cache invalidation and naming things.”
  5. 5. Problèmes avec Rest • Cache (API et apps) • Resources : changement de paradigme (API et apps) • Same Origin Policy (apps) • Authentification (API et apps) • Pas de standard de sécurité évolué (API et apps) • Si besoin de moins de 100ms de latence (essayer d’éviter en interne)
  6. 6. Cool stuff ! • Versioning : Accept-content : application/ vnd.acme.user+json;v=1 • Status code HTTP • Hypertext • Identification par URI • Négociation de contenu : Accept-* (Language et Type) • etc.
  7. 7. Pure Rest :) • Utiliser tous les verbes HTTP • Stateless • Paramètre(s) dans l’URI • Cache
  8. 8. Practical Rest :( • Utiliser seulement GET et POST • Stateful • Les paramètres dans la Query-String ou en POST
  9. 9. Hypermedia • HATEOAS : hypermedia moteur de l’état de l’application • Nœuds liés par des hyperliens
  10. 10. Hypermedia : ok • Auto-documentation, auto-découverte de l’API • Tolérance au changement • Monté en charge toujours possible (scalable)
  11. 11. Hypermedia : nok • Maintenir les liens et les relations • Ajoute de la complexité côté serveur • Pas "encore" de standard (simple, unique) pour JSON
  12. 12. Hypermedia et JSON • JSON-LD : norme Linked Data pour JSON du W3C • HAL : utilisé par Amazon AppStream • Collection+JSON de Mike Amundsen • Siren
  13. 13. Conseils • Pas de verbes dans l’URL • Utiliser des noms au pluriel dans l’URL • Supprimer la complexité dans la Query-String • Pas de version dans l’url • Pas de content type dans l’url • Eviter le practical Rest • POST n'est pas idempotent (unsafe) contrairement à PUT • Les versbes HTTP != CRUD • Penser ressources et pas méthodes ou actions
  14. 14. Richardson Maturity Model • niveau 0 : RPC sur HTTP • niveau 1 : ressources différenciées • niveau 2 : verbes et codes retours HTTP • niveau 3 : contrôles hypermedia
  15. 15. Xavier Carpentier Twitter: @xcapetir contact@xavier-carpentier.com

×