#Restful, really ?
Faire une architecture de type Rest, que cela implique-t-
il vraiment ?
Xavier Carpentier
Twitter: @xca...
Définition
• Representational State Transfer
• Rest est un style d'architecture client / serveur, en
couches avec une inter...
Contexte & implication
• Retour d'expérience développeur
• d'API :communication avec partenaires
• d'applications web et m...
–Phil Karlton
“There are only two hard things in Computer
Science: cache invalidation and naming
things.”
Problèmes avec Rest
• Cache (API et apps)
• Resources : changement de paradigme (API et apps)
• Same Origin Policy (apps)
...
Cool stuff !
• Versioning : Accept-content : application/
vnd.acme.user+json;v=1
• Status code HTTP
• Hypertext
• Identific...
Pure Rest :)
• Utiliser tous les verbes HTTP
• Stateless
• Paramètre(s) dans l’URI
• Cache
Practical Rest :(
• Utiliser seulement GET et POST
• Stateful
• Les paramètres dans la Query-String ou en POST
Hypermedia
• HATEOAS : hypermedia moteur de l’état de
l’application
• Nœuds liés par des hyperliens
Hypermedia : ok
• Auto-documentation, auto-découverte de l’API
• Tolérance au changement
• Monté en charge toujours possib...
Hypermedia : nok
• Maintenir les liens et les relations
• Ajoute de la complexité côté serveur
• Pas "encore" de standard ...
Hypermedia et JSON
• JSON-LD : norme Linked Data pour JSON du W3C
• HAL : utilisé par Amazon AppStream
• Collection+JSON d...
Conseils
• Pas de verbes dans l’URL
• Utiliser des noms au pluriel dans l’URL
• Supprimer la complexité dans la Query-Stri...
Richardson Maturity Model
• niveau 0 : RPC sur HTTP
• niveau 1 : ressources différenciées
• niveau 2 : verbes et codes ret...
Xavier Carpentier
Twitter: @xcapetir
contact@xavier-carpentier.com
Prochain SlideShare
Chargement dans…5
×

Restful, really ? MixIt 2014

1 159 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
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 159
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
4
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

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

×