Qu'est-ce que HATEOAS et le Richardson Maturity Model ?

Question

IT Interview Practice · Accepted Answer

Le **Richardson Maturity Model (RMM)** note à quel point une API est « RESTful » sur quatre niveaux, et **HATEOAS** est le niveau le plus élevé — la contrainte que la plupart des gens sautent.

## Les quatre niveaux

```text
Niveau 0 — « Le marécage du POX » : un URI, une méthode (RPC sur HTTP).
           POST /api  { "action": "getUser", "id": 42 }
Niveau 1 — Resources : de nombreux URI, mais toujours un seul verbe.
           POST /users/42  ,  POST /users/42/delete
Niveau 2 — HTTP Verbs : méthodes + status codes appropriés (où vit la plupart des API « REST »).
           GET /users/42 → 200 ,  DELETE /users/42 → 204
Niveau 3 — Hypermedia Controls (HATEOAS) : les réponses lient à ce que vous pouvez faire ensuite.
```

La plupart des API « REST » en production sont au **Niveau 2** — ressources, méthodes et status codes corrects. C'est généralement suffisant, et c'est une cible parfaitement raisonnable.

## HATEOAS (Niveau 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. L'idée : une réponse inclut des **liens** indiquant au client quelles actions sont disponibles ensuite, de sorte que le client navigue dans l'API en suivant des liens plutôt qu'en codant en dur des URL — comme un humain qui suit des liens sur une page web au lieu de mémoriser chaque URL.

```http
GET /orders/1001 HTTP/1.1
```
```http
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1001,
  "status": "pending",
  "total": 250,
  "_links": {
    "self":   { "href": "/orders/1001" },
    "pay":    { "href": "/orders/1001/payment", "method": "POST" },
    "cancel": { "href": "/orders/1001/cancel",  "method": "POST" }
  }
}
```

Comme l'order est `pending`, le serveur propose les liens `pay` et `cancel`. Une fois payé, ces liens disparaissent et un lien `refund` pourrait apparaître — **le serveur pilote les transitions d'état**, et le client se contente de suivre les liens qu'on lui donne.

## Pourquoi c'est rare

La promesse est le découplage : les clients ne codent pas les URL en dur, donc le serveur peut les restructurer librement. En pratique, la plupart des clients codent quand même en dur, HATEOAS ajoute une réelle complexité, et les formats ne se sont jamais complètement standardisés (HAL, JSON:API, Siren se font tous concurrence). Le bénéfice justifie rarement le coût.

## Pourquoi c'est important

C'est une question senior classique car elle sépare ceux qui **comprennent REST tel qu'il a été défini à l'origine** de ceux qui utilisent « REST » vaguement pour signifier « JSON sur HTTP ». L'intuition précieuse n'est pas de réciter les quatre niveaux — c'est le jugement de dire que le **Niveau 2 est le point d'équilibre pragmatique** tout en sachant que le vrai REST (la définition de Fielding) *exige* HATEOAS, et d'être capable d'expliquer *pourquoi l'industrie l'ignore majoritairement* : le bénéfice de découplage est réel mais rarement réalisé car les clients codent les URL en dur de toute façon, et la complexité ajoutée plus les formats hypermédia concurrents ne sont pas rentables pour les API typiques. Démontrer que vous savez ce qu'*est* HATEOAS, pouvoir montrer un exemple concret de liens pilotés par l'état, et argumenter honnêtement sur le rapport coût/bénéfice — plutôt que d'insister dogmatiquement pour que chaque API soit au Niveau 3 — est exactement le jugement équilibré, fondé sur l'expérience, que les recruteurs sondent.

Les quatre niveaux

HATEOAS (Niveau 3)

Pourquoi c'est rare

Pourquoi c'est important

Questions connexes