Hva er HATEOAS og Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** graderer hvor "RESTful" et API er over fire nivåer, og **HATEOAS** er det øverste nivået — begrensningen de fleste hopper over.

## De fire nivåene

```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 fleste "REST"-API-er i produksjon er på **nivå 2** — korrekte ressurser, metoder og statuskoder. Det er som regel godt nok, og det er et helt fornuftig mål.

## HATEOAS (nivå 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. Ideen: en response inkluderer **lenker** som forteller klienten hvilke handlinger som er tilgjengelige videre, så klienten navigerer API-et ved å følge lenker i stedet for å hardkode URL-er — som et menneske som følger lenker på en nettside i stedet for å memorere 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`, tilbyr serveren lenkene `pay` og `cancel`. Når den er betalt, forsvinner disse lenkene og en `refund`-lenke kan dukke opp — **serveren styrer tilstandsovergangene**, og klienten følger bare de lenkene den får.

## Hvorfor det er sjeldent

Løftet er avkobling: klienter hardkoder ikke URL-er, så serveren kan omstrukturere dem fritt. I praksis hardkoder de fleste klienter uansett, HATEOAS legger til reell kompleksitet, og formatene ble aldri fullt standardisert (HAL, JSON:API, Siren konkurrerer alle). Gevinsten rettferdiggjør sjelden kostnaden.

## Hvorfor det er viktig

Dette er et klassisk spørsmål på seniornivå fordi det skiller de som **forstår REST slik det opprinnelig ble definert** fra de som bruker "REST" løst for å bety "JSON over HTTP". Den verdifulle innsikten er ikke å ramse opp de fire nivåene — det er dømmekraften til å si at **nivå 2 er det pragmatiske sweet spot** samtidig som man vet at ekte REST (Fieldings definisjon) *krever* HATEOAS, og å kunne forklare *hvorfor bransjen stort sett ignorerer det*: avkoblingsfordelen er reell, men sjelden realisert fordi klienter hardkoder URL-er uansett, og den ekstra kompleksiteten pluss konkurrerende hypermedia-formater lønner seg ikke for typiske API-er. Å vise at du vet hva HATEOAS *er*, kan gi et konkret eksempel på tilstandsdrevne lenker, og kan argumentere ærlig om kostnad/nytte — snarere enn dogmatisk å insistere på at hvert API må være nivå 3 — er nettopp den balanserte, erfaringsbaserte dømmekraften intervjuere graver etter.

De fire nivåene

HATEOAS (nivå 3)

Hvorfor det er sjeldent

Hvorfor det er viktig

Relaterte spørsmål