Vad är HATEOAS och Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** graderar hur "RESTful" ett API är över fyra nivåer, och **HATEOAS** är den översta nivån — den constraint de flesta hoppar över.

## De fyra nivåerna

```text
Nivå 0 — "The Swamp of POX": en URI, en method (RPC över HTTP).
         POST /api  { "action": "getUser", "id": 42 }
Nivå 1 — Resources: många URI:er, men fortfarande ett verb.
         POST /users/42  ,  POST /users/42/delete
Nivå 2 — HTTP Verbs: korrekta methods + status codes (där de flesta "REST"-API:er bor).
         GET /users/42 → 200 ,  DELETE /users/42 → 204
Nivå 3 — Hypermedia Controls (HATEOAS): responses länkar till vad du kan göra härnäst.
```

De flesta "REST"-API:er i produktion är på **Nivå 2** — korrekta resurser, methods och status codes. Det är oftast tillräckligt bra, och det är ett fullt rimligt mål.

## HATEOAS (Nivå 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. Idén: en response inkluderar **länkar** som talar om för client:en vilka handlingar som är tillgängliga härnäst, så att client:en navigerar API:et genom att följa länkar snarare än att hårdkoda URL:er — som en människa som följer länkar på en webbsida i stället för att memorera varje 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" }
  }
}
```

Eftersom order:n är `pending` erbjuder servern länkarna `pay` och `cancel`. När den väl är betald försvinner de länkarna och en `refund`-länk kan dyka upp — **servern driver tillståndsövergångarna**, och client:en följer bara vilka länkar den ges.

## Varför det är sällsynt

Löftet är decoupling: clients hårdkodar inte URL:er, så servern kan omstrukturera dem fritt. I praktiken hårdkodar de flesta clients ändå, HATEOAS tillför verklig komplexitet, och formaten standardiserades aldrig helt (HAL, JSON:API, Siren konkurrerar alla). Utdelningen motiverar sällan kostnaden.

## Varför det är viktigt

Detta är en klassisk fråga på seniornivå eftersom den skiljer dem som **förstår REST som det ursprungligen definierades** från dem som använder "REST" löst för att betyda "JSON över HTTP." Den värdefulla insikten är inte att rabbla de fyra nivåerna — det är omdömet att säga att **Nivå 2 är den pragmatiska sweet spot:en** samtidigt som man vet att äkta REST (Fieldings definition) *kräver* HATEOAS, och att kunna förklara *varför branschen mestadels ignorerar det*: decoupling-fördelen är verklig men förverkligas sällan eftersom clients hårdkodar URL:er ändå, och den tillkommande komplexiteten plus konkurrerande hypermedia-format lönar sig inte för typiska API:er. Att visa att du vet vad HATEOAS *är*, kan visa ett konkret exempel med tillståndsdrivna länkar, och kan argumentera ärligt om kostnad/nytta — snarare än att dogmatiskt insistera på att varje API måste vara Nivå 3 — är precis det balanserade, erfarenhetsbaserade omdöme intervjuare undersöker.

De fyra nivåerna

HATEOAS (Nivå 3)

Varför det är sällsynt

Varför det är viktigt

Relaterade frågor