Mitä ovat HATEOAS ja Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** arvostelee, kuinka "RESTful" API on, neljän tason kautta, ja **HATEOAS** on ylin taso — rajoite, jonka useimmat ohittavat.

## Neljä tasoa

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

Useimmat tuotannon "REST"-API:t ovat **Tasolla 2** — oikeat resurssit, metodit ja status codet. Se on yleensä riittävän hyvä, ja se on täysin järkevä tavoite.

## HATEOAS (Taso 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. Idea: vastaus sisältää **linkkejä**, jotka kertovat clientille, mitkä toiminnot ovat seuraavaksi käytettävissä, joten client navigoi API:a seuraamalla linkkejä sen sijaan että kovakoodaisi URL:t — kuten ihminen seuraa linkkejä verkkosivulla sen sijaan että muistaisi ulkoa jokaisen URL:n.

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

Koska tilaus on `pending`, palvelin tarjoaa `pay`- ja `cancel`-linkit. Maksun jälkeen nuo linkit katoavat ja `refund`-linkki saattaa ilmestyä — **palvelin ohjaa tilasiirtymiä**, ja client seuraa vain sille annettuja linkkejä.

## Miksi se on harvinaista

Lupaus on decoupling: clientit eivät kovakoodaa URL:iä, joten palvelin voi rakenteistaa ne vapaasti uudelleen. Käytännössä useimmat clientit kovakoodaavat silti, HATEOAS lisää todellista monimutkaisuutta, eivätkä muodot koskaan täysin standardoituneet (HAL, JSON:API, Siren kilpailevat kaikki). Hyöty harvoin oikeuttaa kustannuksen.

## Miksi se on tärkeää

Tämä on klassinen senior-tason kysymys, koska se erottaa ne, jotka **ymmärtävät REST:in alkuperäisen määritelmän mukaisesti**, niistä, jotka käyttävät "REST"-sanaa löyhästi tarkoittaen "JSON HTTP:n yli". Arvokas oivallus ei ole neljän tason lausuminen — se on harkinta sanoa, että **Taso 2 on pragmaattinen makea piste** samalla tietäen, että todellinen REST (Fieldingin määritelmä) *vaatii* HATEOAS:n, ja kyeten selittämään, *miksi ala enimmäkseen sivuuttaa sen*: decoupling-hyöty on todellinen mutta harvoin toteutuu, koska clientit kovakoodaavat URL:t joka tapauksessa, eivätkä lisätty monimutkaisuus plus kilpailevat hypermedia-muodot maksa itseään takaisin tyypillisille API:eille. Sen osoittaminen, että tiedät mitä HATEOAS *on*, osaat näyttää konkreettisen tilaohjattujen linkkien esimerkin ja osaat argumentoida rehellisesti kustannus/hyöty-suhteesta — sen sijaan että dogmaattisesti vaatisit jokaisen API:n olevan Tasoa 3 — on juuri sitä tasapainoista, kokemukseen perustuvaa harkintaa, jota haastattelijat luotaavat.

Neljä tasoa

HATEOAS (Taso 3)

Miksi se on harvinaista

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset