Czym są HATEOAS i Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** ocenia, jak „RESTful" jest API, w czterech poziomach, a **HATEOAS** to najwyższy poziom — ograniczenie, które większość pomija.

## Cztery poziomy

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

Większość produkcyjnych „REST" API jest na **Poziomie 2** — poprawne zasoby, metody i kody statusu. To zwykle wystarczająco dobre i jest całkowicie rozsądnym celem.

## HATEOAS (Poziom 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. Idea: odpowiedź zawiera **linki** mówiące klientowi, jakie akcje są dostępne dalej, więc klient nawiguje po API, podążając za linkami, zamiast twardo kodować URL-e — jak człowiek podążający za linkami na stronie WWW zamiast zapamiętywania każdego URL-a.

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

Ponieważ zamówienie jest `pending`, serwer oferuje linki `pay` i `cancel`. Po opłaceniu te linki znikają, a może pojawić się link `refund` — **serwer napędza przejścia stanów**, a klient po prostu podąża za tym, jakiekolwiek linki dostanie.

## Dlaczego jest rzadkie

Obietnicą jest odsprzężenie (decoupling): klienci nie kodują twardo URL-i, więc serwer może je swobodnie restrukturyzować. W praktyce większość klientów i tak koduje twardo, HATEOAS dodaje realną złożoność, a formaty nigdy się w pełni nie ustandaryzowały (HAL, JSON:API, Siren rywalizują ze sobą). Zwrot rzadko uzasadnia koszt.

## Dlaczego to ważne

To klasyczne pytanie na poziomie senior, bo oddziela ludzi, którzy **rozumieją REST tak, jak został pierwotnie zdefiniowany**, od tych, którzy używają „REST" luźno w znaczeniu „JSON przez HTTP". Wartościowe spostrzeżenie to nie recytowanie czterech poziomów — to osąd, by powiedzieć, że **Poziom 2 to pragmatyczny złoty środek**, jednocześnie wiedząc, że prawdziwy REST (definicja Fieldinga) *wymaga* HATEOAS, i umiejętność wyjaśnienia, *dlaczego branża w większości go ignoruje*: korzyść z odsprzężenia jest realna, ale rzadko urzeczywistniana, bo klienci i tak kodują URL-e twardo, a dodana złożoność plus rywalizujące formaty hipermediów nie opłacają się dla typowych API. Pokazanie, że wiesz, czym HATEOAS *jest*, potrafisz przedstawić konkretny przykład linków sterowanych stanem i uczciwie argumentować o koszcie/korzyści — zamiast dogmatycznie nalegać, że każde API musi być na Poziomie 3 — to dokładnie ten zrównoważony, oparty na doświadczeniu osąd, którego rozmówcy szukają.

Cztery poziomy

HATEOAS (Poziom 3)

Dlaczego jest rzadkie

Dlaczego to ważne

Powiązane pytania