Le document présente le modèle de maturité de Richardson pour évaluer la conformité d'une API avec les principes REST. Il décrit les différents niveaux de sophistication d'une API RESTful, allant de RPC en HTTP à l'intégration de HATEOAS au niveau 3, mettant l'accent sur les contraintes de Roy Fielding. Il souligne également que le format JSON ne fait pas automatiquement une API RESTful et mentionne des travaux en cours pour standardiser des formats hypermédia.

1. REST
Modèle de maturité de Richardson
Pour évaluer la RESTitude de votre API
Par : Ouadie LAHDIOUI - Le : 25/11/2015

2. AVEZ-VOUS DÉJÀ DÉVELOPPÉ
UNE API RESTFUL ?
2

3. HTTP
3
HYPERTEXT TRANSFERT PROTOCOL

4. HYPERTEXT TRANSFERT PROTOCOL
RAPPELS SUR HTTP
4
+ Stateless
+ Half duplex
+ Requêtes / Réponses
+ Méthodes idempotentes et/ou sûres
+ Codes de retour
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API

5. <Version> - <Date>© SQLI Enterprise – SQLI GROUP | 2015 5Source : http://restlet.com/http-status-codes-map

6. REST
6
REPRESENTATIONAL STATE TRANSFERT

7. REPRESENTATIONAL STATE TRANSFERT
REST
7
+ Un ensembles de principes définis dans la thèse de Roy Fielding dans les années 2000
+ Roy Fielding est l’un des 8 fondateurs de la fondation Apache
+ REST est
Ensemble de conventions et de bonnes pratiques à respecter
Style d’architecture : structurant, efficace, évolutif et indépendant des mises en œuvre
Une approche pour construire une API
+ REST n’est surtout pas
Un format
Un protocole
Un standard
Une technologie à part entière
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API

8. LES CONTRAINTES DE ROY FIELDING
8
1. Le serveur et le client sont indépendants. L'interface utilisateur est situé côté client et le
stockage est située côté serveur
2. Stateless = Aucune variable de session ou autre état volatile ne doit être enregistré côté
serveur
3. Mise en cache
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
1/2

9. LES CONTRAINTES DE ROY FIELDING
9
4. Une interface uniforme :
+ Une identification des ressources.
+ Les ressources sont manipulées via des représentations
+ Auto-description
+ Hypermédia comme moteur d'application (HATEOAS)
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
6. Code à la demande (optionnelle)
2/2
5. Architecture multi-couches

10. MODÈLE DE MATURITÉ DE RICHARDSON
10
EXEMPLE PUBLIÉ PAR MARTIN FOWLER

11. RICHARDSON MATURITY MODEL
LE MODÈLE DE MATURITÉ DE RICHARDSON
11
+ Développé par Léonard Richardson
+ Il compte 4 niveaux (0-3), où le niveau 3 représente une vraie API RESTful
+ Ces 4 niveaux permettent d’évaluer une API par rapport aux contraintes REST
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API

12. 1/2 PLAIN OLD XML
NIVEAU 0 - LE RPC SUR HTTP EN POX
12
+ Le protocole est uniquement utilisé à des fins de transport du message
+ Tout circule via un seul et unique point d’entrée
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
+ Niveau 0 : État basique avec des XML dans tous les sens

13. 2/2 PLAIN OLD XML
NIVEAU 0 - LE RPC SUR HTTP EN POX
13REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
1
2
3
4
5

14. 1/2
NIVEAU 1 - RESSOURCES
14
+ Resources sont identifiées avec URI
+ Pas de sémantique
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
+ Niveau 1 : Ajout de la notion de ressources

15. 2/2
NIVEAU 1 - RESSOURCES
15REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
1 2
3

16. 1/2
NIVEAU 2 - VERBES ET CODES RETOURS HTTP
16
+ Multiples resources
+ Utilisation sémantiquement correcte des verbes HTTP
+ Utilisation correcte des code de réponse
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
+ Niveau 2 : Ajout de verbes de statut et de codes d’état

17. NIVEAU 2 - VERBES ET CODES RETOURS HTTP
17REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
1
2
3
4
5
2/2

18. 1/2 HYPERTEXT AS THE ENGINE OF APPLICATION STATE
NIVEAU 3 - CONTRÔLE HYPERMEDIA (HATEOAS)
18
+ Formats hypermedias : HTML, HAL, JSON-LD
+ Resources auto-descriptives
+ État et comportement accessible via les représentations
+ HATEOAS
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
+ Niveau 3 : Contrôle hypermedia (HATEOAS)

19. 2/2 HYPERTEXT AS THE ENGINE OF APPLICATION STATE
NIVEAU 3 - CONTRÔLE HYPERMEDIA (HATEOAS)
19REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
1
2
3
4

20. RESSOURCE VS PRÉSENTATION
20
+ Représentation = représente l’état de la ressource
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
+ Selon Roy, une ressource peut être n’import quoi :
+ Négociation de contenu

21. API RESTFUL
21
+ Une API qui respecte les principes de l’architecture REST
+ Techniquement, on doit parler d’API RESTful, pas d’API REST
+ Si votre API n’est pas de niveau 3, ne prétendez pas faire du REST car c’est faux
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API

22. API RESTFUL
22
+ Si votre API se contente de renvoyer juste des objets sérialisés au format JSON/XML/…
parlez simplement d’API ou d’ API HTTP !
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
+ Il est possible d’utiliser divers protocoles de transfert tels que SNMP, SMTP et d’autres, et
votre API restera bel et bien une API RESTful.

23. MON API EST RESTFUL LORSQUE J’UTILISE JSON ?
23
+ Réponse courte : non
+ Réponse longue : non
+ JSON n’est pas un format hypermédia
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API
+ Des travaux de standardisation sont en cours pour rendre JSON hypermédia :
+ JSON-LD
+ HAL : Hypertext Application Language
+ SIREN

24. 24
BON ALORS, VOTRE API EST-ELLE TOUJOURS RESTFUL ?
REST : Modèle de maturité de Richardson, Pour évaluer la RESTitude de votre API

25. MERCI
25
Pour aller plus loin… :
• Thèse de Roy T. Fielding : Architectural Styles and the Design of Network-based SoftwareSources :
• Blog de Leonard Richardson
• Blog de Martin Fowler sur le RMM
• Nobody understands REST but it is ok ;-) - par William Durand
• Api hypermedia par David MARTIN - Devoxx FR 2015
• The never-ending REST API design debate by Guillaume Laforge