Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Restful, really ? MixIt 2014

1 258 vues

Publié le

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 ?

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

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

×