Wat is HATEOAS en het Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

Het **Richardson Maturity Model (RMM)** beoordeelt hoe "RESTful" een API is over vier niveaus, en **HATEOAS** is het hoogste niveau — de constraint die de meeste mensen overslaan.

## De vier niveaus

```text
Level 0 — "The Swamp of POX": one URI, one method (RPC over HTTP).
          POST /api  { "action": "getUser", "id": 42 }
Level 1 — Resources: many URIs, but still one verb.
          POST /users/42  ,  POST /users/42/delete
Level 2 — HTTP Verbs: proper methods + status codes (where most "REST" APIs live).
          GET /users/42 → 200 ,  DELETE /users/42 → 204
Level 3 — Hypermedia Controls (HATEOAS): responses link to what you can do next.
```

De meeste productie-"REST"-API's zitten op **Level 2** — correcte resources, methoden en statuscodes. Dat is meestal goed genoeg, en het is een volkomen redelijk doel.

## HATEOAS (Level 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. Het idee: een response bevat **links** die de client vertellen welke acties er als volgende beschikbaar zijn, zodat de client door de API navigeert door links te volgen in plaats van URL's te hardcoden — zoals een mens links op een webpagina volgt in plaats van elke URL uit het hoofd te leren.

```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" }
  }
}
```

Omdat de order `pending` is, biedt de server `pay`- en `cancel`-links aan. Eenmaal betaald verdwijnen die links en kan er een `refund`-link verschijnen — **de server stuurt de statusovergangen**, en de client volgt gewoon welke links hij ook krijgt.

## Waarom het zeldzaam is

De belofte is ontkoppeling: clients hardcoden geen URL's, dus de server kan ze vrij herstructureren. In de praktijk hardcoden de meeste clients toch, voegt HATEOAS echte complexiteit toe, en zijn formaten nooit volledig gestandaardiseerd (HAL, JSON:API, Siren concurreren allemaal). De opbrengst rechtvaardigt de kosten zelden.

## Waarom het belangrijk is

Dit is een klassieke seniorvraag omdat hij mensen die **REST begrijpen zoals oorspronkelijk gedefinieerd** scheidt van wie "REST" losjes gebruikt om "JSON over HTTP" te bedoelen. Het waardevolle inzicht is niet de vier niveaus opdreunen — het is het oordeel om te zeggen dat **Level 2 de pragmatische sweet spot is** terwijl je weet dat echte REST (Fieldings definitie) HATEOAS *vereist*, en kunnen uitleggen *waarom de industrie het grotendeels negeert*: het ontkoppelingsvoordeel is echt maar wordt zelden gerealiseerd omdat clients URL's toch hardcoden, en de extra complexiteit plus concurrerende hypermedia-formaten lonen niet voor typische API's. Aantonen dat je weet wat HATEOAS *is*, een concreet voorbeeld van state-gestuurde links kunnen tonen, en eerlijk over de kosten/baten kunnen argumenteren — in plaats van dogmatisch te eisen dat elke API Level 3 moet zijn — is precies het gebalanceerde, op ervaring gebaseerde oordeel waar interviewers naar polsen.

De vier niveaus

HATEOAS (Level 3)

Waarom het zeldzaam is

Waarom het belangrijk is

Gerelateerde vragen