Che cos’è HATEOAS e il Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

Il **Richardson Maturity Model (RMM)** valuta quanto "RESTful" sia un'API attraverso quattro livelli, e **HATEOAS** è il livello più alto — il vincolo che la maggior parte delle persone salta.

## I quattro livelli

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

La maggior parte delle API "REST" in produzione è a **Livello 2** — risorse, metodi e status code corretti. Di solito è abbastanza buono, ed è un obiettivo perfettamente ragionevole.

## HATEOAS (Livello 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. L'idea: una risposta include **link** che dicono al client quali azioni sono disponibili in seguito, così il client naviga l'API seguendo i link anziché fare hardcoding degli URL — come una persona che segue i link su una pagina web invece di memorizzare ogni 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" }
  }
}
```

Poiché l'ordine è `pending`, il server offre i link `pay` e `cancel`. Una volta pagato, quei link spariscono e potrebbe comparire un link `refund` — **il server guida le transizioni di stato**, e il client si limita a seguire i link che gli vengono dati.

## Perché è raro

La promessa è il disaccoppiamento: i client non fanno hardcoding degli URL, quindi il server può ristrutturarli liberamente. Nella pratica la maggior parte dei client fa comunque hardcoding, HATEOAS aggiunge complessità reale, e i formati non si sono mai standardizzati del tutto (HAL, JSON:API, Siren competono tutti). Il beneficio raramente giustifica il costo.

## Perché è importante

Questa è una domanda senior classica perché separa chi **capisce REST come originariamente definito** da chi usa "REST" in modo lasco per intendere "JSON su HTTP". L'intuizione preziosa non è recitare i quattro livelli — è il giudizio di dire che il **Livello 2 è il punto dolce pragmatico** pur sapendo che il vero REST (la definizione di Fielding) *richiede* HATEOAS, ed essere in grado di spiegare *perché l'industria per lo più lo ignora*: il beneficio del disaccoppiamento è reale ma raramente realizzato perché i client fanno comunque hardcoding degli URL, e la complessità aggiuntiva più i formati ipermediali concorrenti non ripagano per le API tipiche. Dimostrare che sai cos'*è* HATEOAS, saper mostrare un esempio concreto di link guidati dallo stato, e saper argomentare onestamente su costi/benefici — anziché insistere dogmaticamente che ogni API debba essere di Livello 3 — è esattamente il giudizio equilibrato e basato sull'esperienza che gli intervistatori stanno sondando.

I quattro livelli

HATEOAS (Livello 3)

Perché è raro

Perché è importante

Domande correlate