Mi a HATEOAS és a Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

A **Richardson Maturity Model (RMM)** négy szinten osztályozza, mennyire "RESTful" egy API, és a **HATEOAS** a legfelső szint — az a megkötés, amelyet a legtöbben kihagynak.

## A négy szint

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

A legtöbb éles "REST" API a **2. szinten** van — helyes erőforrások, metódusok és status code-ok. Ez általában elég jó, és teljesen ésszerű cél.

## HATEOAS (3. szint)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. A gondolat: egy válasz **linkeket** tartalmaz, amelyek megmondják a kliensnek, milyen műveletek érhetők el következőként, így a kliens linkek követésével navigálja az API-t, ahelyett, hogy URL-eket égetne be — mint egy ember, aki egy weboldalon linkeket követ, ahelyett, hogy minden URL-t megjegyezne.

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

Mivel az order `pending`, a server `pay` és `cancel` linkeket kínál. Fizetés után ezek a linkek eltűnnek, és egy `refund` link jelenhet meg — **a server vezérli az állapotátmeneteket**, a kliens pedig csak követi a kapott linkeket.

## Miért ritka

Az ígéret a szétcsatolás: a kliensek nem égetik be az URL-eket, így a server szabadon átstrukturálhatja őket. A gyakorlatban a legtöbb kliens úgyis beéget, a HATEOAS valós komplexitást ad hozzá, és a formátumok sosem szabványosodtak teljesen (a HAL, JSON:API, Siren mind versengenek). A haszon ritkán indokolja a költséget.

## Miért fontos

Ez egy klasszikus senior szintű kérdés, mert elválasztja azokat, akik **a REST-et az eredeti definíciója szerint értik**, azoktól, akik a "REST"-et lazán "JSON HTTP fölött" értelemben használják. Az értékes felismerés nem a négy szint felmondása — hanem az ítélőképesség kimondani, hogy **a 2. szint a pragmatikus édespont**, miközben tudod, hogy a valódi REST (Fielding definíciója) *megköveteli* a HATEOAS-t, és el tudod magyarázni, *miért hagyja figyelmen kívül az iparág többnyire*: a szétcsatolási előny valós, de ritkán valósul meg, mert a kliensek úgyis beégetik az URL-eket, és a hozzáadott komplexitás plusz a versengő hypermedia-formátumok nem térülnek meg a tipikus API-knál. Ha megmutatod, hogy tudod, *mi* a HATEOAS, be tudsz mutatni egy konkrét, állapotvezérelt linkes példát, és őszintén tudsz érvelni a költség/haszon mellett — ahelyett, hogy dogmatikusan ragaszkodnál ahhoz, hogy minden API-nak 3. szintűnek kell lennie —, pontosan ez a kiegyensúlyozott, tapasztalat-alapú ítélőképesség, amit az interjúztatók keresnek.

A négy szint

HATEOAS (3. szint)

Miért ritka

Miért fontos

Kapcsolódó kérdések