Kaj je HATEOAS in kaj je Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** oceni, kako "RESTful" je API, čez štiri ravni, in **HATEOAS** je najvišja raven — omejitev, ki jo večina preskoči.

## Štiri ravni

```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.
```

Večina produkcijskih "REST" API-jev je na **Ravni 2** — pravilni viri, metode in status kode. To je običajno dovolj dobro in povsem razumen cilj.

## HATEOAS (Raven 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. Ideja: odgovor vključuje **povezave (links)**, ki odjemalcu povedo, katera dejanja so na voljo naslednja, tako da odjemalec po API-ju krmari s sledenjem povezavam, namesto da bi trdo kodiral URL-je — kot človek, ki sledi povezavam na spletni strani, namesto da bi si zapomnil vsak 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" }
  }
}
```

Ker je naročilo `pending`, strežnik ponudi povezavi `pay` in `cancel`. Ko je plačano, ti povezavi izgineta in lahko se pojavi povezava `refund` — **strežnik poganja prehode stanj**, odjemalec pa le sledi povezavam, ki jih dobi.

## Zakaj je redek

Obljuba je razklopitev (decoupling): odjemalci ne trdo kodirajo URL-jev, zato jih strežnik lahko prosto preureja. V praksi večina odjemalcev vseeno trdo kodira, HATEOAS doda resnično kompleksnost, oblike pa nikoli niso bile popolnoma standardizirane (HAL, JSON:API, Siren tekmujejo). Donos redko upraviči ceno.

## Zakaj je to pomembno

To je klasično senior vprašanje, ker loči tiste, ki **razumejo REST, kot je bil prvotno opredeljen**, od tistih, ki "REST" uporabljajo ohlapno kot "JSON prek HTTP". Dragocen uvid ni recitiranje štirih ravni — je presoja, da rečete, da je **Raven 2 pragmatična zlata sredina**, ob zavedanju, da pravi REST (Fieldingova definicija) *zahteva* HATEOAS, in sposobnost razložiti, *zakaj ga panoga večinoma ignorira*: korist razklopitve je resnična, a redko uresničena, ker odjemalci URL-je vseeno trdo kodirajo, dodana kompleksnost in tekmujoče hipermedijske oblike pa se za tipične API-je ne izplačajo. Pokazati, da veste, *kaj* HATEOAS je, znati prikazati konkreten primer povezav, ki jih poganja stanje, in pošteno argumentirati o ceni/koristi — namesto dogmatičnega vztrajanja, da mora biti vsak API na Ravni 3 — je natanko uravnotežena, na izkušnjah temelječa presoja, ki jo spraševalci iščejo.

Štiri ravni

HATEOAS (Raven 3)

Zakaj je redek

Zakaj je to pomembno

Povezana vprašanja