Le modèle de Richardson — Niveau 0 : le tunnel POX/RPC
Le gain du jour : comprendre pourquoi « utiliser HTTP » ne veut pas dire « faire du REST », et savoir reconnaître le niveau 0 — le point de départ le moins « RESTful » qui soit.
« RESTful » n’est pas tout ou rien
Beaucoup d’API se disent « REST » simplement parce qu’elles échangent du JSON sur HTTP. En 2008, Leonard Richardson a proposé un modèle en 4 niveaux (0 à 3) pour mesurer à quel point une API adopte réellement les contraintes REST de Fielding. Martin Fowler a popularisé ce modèle sous le nom de Richardson Maturity Model. On va gravir ces 4 niveaux un par un, sur les 4 prochaines leçons — chaque niveau ajoute une contrainte au précédent, sans jamais revenir en arrière.
Niveau 0 : le tunnel POX/RPC ← cette leçon
Niveau 1 : les ressources
Niveau 2 : les verbes HTTP
Niveau 3 : HATEOAS (hypermédia)Niveau 0 : HTTP comme simple tunnel de transport
Au niveau 0, HTTP ne sert qu’à transporter des appels — un peu comme un tuyau. Toute la logique métier (quelle action effectuer, sur quoi) est encodée dans le corps de la requête, pas dans l’URI ni dans le verbe HTTP. C’est le style RPC (Remote Procedure Call) : on appelle une fonction à distance comme si c’était une fonction locale.
Exemple typique (souvent appelé POX — Plain Old XML, ou son équivalent JSON) :
POST /api HTTP/1.1
Content-Type: application/json
{"action": "getUser", "userId": 42}POST /api HTTP/1.1
Content-Type: application/json
{"action": "deleteUser", "userId": 42}Remarque : une seule URI (/api), un seul verbe (POST, presque toujours), et
tout le sens de la requête est caché dans le corps JSON. Le serveur doit ouvrir et
inspecter chaque requête pour savoir quoi faire — HTTP n’aide en rien à router ou à
comprendre l’intention.
Les web services SOAP, très répandus dans les années 2000 (souvent en entreprise),
sont l’archétype du niveau 0 : une seule URL de service, toujours en POST, avec une
enveloppe XML qui précise l’opération demandée. SOAP a son propre écosystème de normes
(WSDL, WS-Security…), mais du point de vue de Richardson, il reste au niveau 0 : HTTP
n’y est qu’un tuyau.
Pourquoi c’est un problème
Ce style fonctionne, mais il renonce à tout ce que HTTP offre gratuitement :
- Pas de cache : un cache HTTP (navigateur, CDN, proxy) décide de mettre en cache
selon le verbe et l’URI. Ici, tout passe par
POST /api— rien n’est cachable. - Pas de sémantique standard : impossible de deviner, juste en lisant la requête, si elle est sûre ou destructrice — il faut lire le corps entier.
- Outils génériques inutiles : un outil qui comprend REST (un navigateur, un
générateur de documentation, un firewall applicatif) ne peut rien déduire de
POST /api— il doit connaître le format interne de chaque application. - Codes de statut peu informatifs : le serveur répond souvent
200 OKmême en cas d’erreur métier, avec l’erreur cachée dans le corps ({"error": "user not found"}) — les outils qui surveillent les taux d’erreur HTTP (4xx/5xx) ne voient rien passer.
Pour un usage interne très simple, ou un protocole RPC assumé (gRPC, GraphQL — qui ont chacun leurs propres forces), niveau 0 est un choix cohérent. Le problème survient quand on prétend faire du REST tout en restant au niveau 0 : on perd les bénéfices de HTTP sans le savoir.
Vérifie ta compréhension
1. Au niveau 0 du modèle de Richardson, où vit la logique métier de la requête ?
2. Pourquoi une API de niveau 0 est-elle difficile à mettre en cache ?
3. SOAP est l'exemple historique le plus cité de quel niveau du modèle de Richardson ?
Pour aller plus loin
📖 Source principale : Martin Fowler, « Richardson Maturity Model » — l’article de référence qui a popularisé ce modèle, avec le niveau 0 détaillé en premier.