Hvad er HATEOAS og Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** bedømmer, hvor "RESTful" en API er, på tværs af fire niveauer, og **HATEOAS** er det øverste niveau — den constraint, de fleste springer over.

## De fire niveauer

```text
Niveau 0 — "The Swamp of POX": én URI, én method (RPC over HTTP).
           POST /api  { "action": "getUser", "id": 42 }
Niveau 1 — Resources: mange URI'er, men stadig ét udsagnsord.
           POST /users/42  ,  POST /users/42/delete
Niveau 2 — HTTP Verbs: korrekte methods + status-koder (hvor de fleste "REST"-APIs bor).
           GET /users/42 → 200 ,  DELETE /users/42 → 204
Niveau 3 — Hypermedia Controls (HATEOAS): responses linker til, hvad du kan gøre nu.
```

De fleste "REST"-APIs i produktion er på **Niveau 2** — korrekte resources, methods og status-koder. Det er som regel godt nok, og det er et helt rimeligt mål.

## HATEOAS (Niveau 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. Idéen: et response inkluderer **links**, der fortæller clienten, hvilke handlinger der er tilgængelige som de næste, så clienten navigerer i API'en ved at følge links frem for at hardkode URL'er — ligesom et menneske følger links på en webside i stedet for at huske hver 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" }
  }
}
```

Fordi ordren er `pending`, tilbyder serveren `pay`- og `cancel`-links. Når den er betalt, forsvinder de links, og et `refund`-link kan dukke op — **serveren driver tilstandsovergangene**, og clienten følger blot de links, den får.

## Hvorfor det er sjældent

Løftet er decoupling: clients hardkoder ikke URL'er, så serveren kan omstrukturere dem frit. I praksis hardkoder de fleste clients alligevel, HATEOAS tilføjer reel kompleksitet, og formaterne blev aldrig fuldt standardiseret (HAL, JSON:API, Siren konkurrerer alle). Udbyttet retfærdiggør sjældent omkostningen.

## Hvorfor det betyder noget

Dette er et klassisk seniorspørgsmål, fordi det adskiller dem, der **forstår REST som oprindeligt defineret**, fra dem, der bruger "REST" løst i betydningen "JSON over HTTP". Den værdifulde indsigt er ikke at fremsige de fire niveauer — det er dømmekraften til at sige, at **Niveau 2 er det pragmatiske sweet spot**, samtidig med at man ved, at ægte REST (Fieldings definition) *kræver* HATEOAS, og at kunne forklare *hvorfor branchen mest ignorerer det*: decoupling-fordelen er reel, men realiseres sjældent, fordi clients hardkoder URL'er alligevel, og den ekstra kompleksitet plus konkurrerende hypermedia-formater betaler sig ikke for typiske APIs. At demonstrere, at du ved, hvad HATEOAS *er*, kan vise et konkret eksempel med tilstandsdrevne links, og kan argumentere ærligt om omkostning/udbytte — frem for dogmatisk at insistere på, at enhver API skal være Niveau 3 — er præcis den balancerede, erfaringsbaserede dømmekraft, interviewere borer efter.

De fire niveauer

HATEOAS (Niveau 3)

Hvorfor det er sjældent

Hvorfor det betyder noget

Relaterede spørgsmål