Ce sunt HATEOAS și Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

**Richardson Maturity Model (RMM)** notează cât de „RESTful" este un API pe patru niveluri, iar **HATEOAS** este nivelul de vârf — constrângerea pe care majoritatea o sar.

## Cele patru niveluri

```text
Nivel 0 — „Mlaștina POX”: un URI, o metodă (RPC peste HTTP).
          POST /api  { "action": "getUser", "id": 42 }
Nivel 1 — Resources: multe URI-uri, dar tot un singur verb.
          POST /users/42  ,  POST /users/42/delete
Nivel 2 — HTTP Verbs: metode corecte + status code-uri (unde stau majoritatea API-urilor „REST”).
          GET /users/42 → 200 ,  DELETE /users/42 → 204
Nivel 3 — Hypermedia Controls (HATEOAS): răspunsurile leagă spre ce poți face în continuare.
```

Majoritatea API-urilor „REST" din producție sunt la **Nivelul 2** — resurse, metode și status code-uri corecte. De obicei asta este suficient de bine și este o țintă perfect rezonabilă.

## HATEOAS (Nivelul 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. Ideea: un răspuns include **link-uri** care spun clientului ce acțiuni sunt disponibile în continuare, așa că clientul navighează API-ul urmând link-uri în loc să hardcodeze URL-uri — ca un om care urmează link-uri pe o pagină web în loc să memoreze fiecare 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" }
  }
}
```

Pentru că comanda este `pending`, serverul oferă link-urile `pay` și `cancel`. Odată plătită, acele link-uri dispar și ar putea apărea un link `refund` — **serverul conduce tranzițiile de stare**, iar clientul doar urmează orice link-uri i se dau.

## De ce este rar

Promisiunea este decuplarea: clienții nu hardcodează URL-uri, așa că serverul le poate restructura liber. În practică, majoritatea clienților hardcodează oricum, HATEOAS adaugă complexitate reală, iar formatele nu s-au standardizat niciodată complet (HAL, JSON:API, Siren concurează toate). Câștigul rareori justifică costul.

## De ce contează

Aceasta este o întrebare senior clasică pentru că separă oamenii care **înțeleg REST așa cum a fost definit inițial** de cei care folosesc „REST" lejer pentru a însemna „JSON peste HTTP". Perspectiva valoroasă nu este recitarea celor patru niveluri — este judecata de a spune că **Nivelul 2 este punctul dulce pragmatic**, știind totodată că REST-ul adevărat (definiția lui Fielding) *necesită* HATEOAS și fiind capabil să explici *de ce industria îl ignoră în mare parte*: beneficiul de decuplare este real, dar rareori realizat pentru că clienții hardcodează URL-uri oricum, iar complexitatea adăugată plus formatele hypermedia concurente nu merită pentru API-uri tipice. A demonstra că știi ce *este* HATEOAS, a putea arăta un exemplu concret de link-uri conduse de stare și a putea argumenta onest despre cost/beneficiu — în loc să insiști dogmatic că fiecare API trebuie să fie la Nivelul 3 — este exact judecata echilibrată, bazată pe experiență, pe care o sondează intervievatorii.

Cele patru niveluri

HATEOAS (Nivelul 3)

De ce este rar

De ce contează

Întrebări conexe