Ce document discute des principes fondamentaux de l'architecture REST, abordant ses implications et les défis associés tels que la gestion du cache, l'authentification et l'absence de standards de sécurité. Il propose également des conseils pratiques pour mieux concevoir des API en respectant les principes REST, tout en différenciant entre le REST pur et le REST pratique. Enfin, il évoque le modèle de maturité de Richardson pour évaluer la sophistication des API REST.

1. #Restful, really ?
Faire une architecture de type Rest, que cela implique-t-
il vraiment ?
Xavier Carpentier
Twitter: @xcapetir
contact@xavier-
carpentier.com

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. 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. –Phil Karlton
“There are only two hard things in Computer
Science: cache invalidation and naming
things.”

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. 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. Pure Rest :)
• Utiliser tous les verbes HTTP
• Stateless
• Paramètre(s) dans l’URI
• Cache

8. Practical Rest :(
• Utiliser seulement GET et POST
• Stateful
• Les paramètres dans la Query-String ou en POST

9. Hypermedia
• HATEOAS : hypermedia moteur de l’état de
l’application
• Nœuds liés par des hyperliens

10. Hypermedia : ok
• Auto-documentation, auto-découverte de l’API
• Tolérance au changement
• Monté en charge toujours possible (scalable)

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. Hypermedia et JSON
• JSON-LD : norme Linked Data pour JSON du W3C
• HAL : utilisé par Amazon AppStream
• Collection+JSON de Mike Amundsen
• Siren

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. 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. Xavier Carpentier
Twitter: @xcapetir
contact@xavier-carpentier.com