¿Qué es HATEOAS y el Richardson Maturity Model?

Question

IT Interview Practice · Accepted Answer

El **Richardson Maturity Model (RMM)** califica cuán "RESTful" es una API a través de cuatro niveles, y **HATEOAS** es el nivel más alto — la restricción que la mayoría se salta.

## Los cuatro niveles

```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 mayoría de las APIs "REST" en producción están en el **Nivel 2** — recursos, methods y status codes correctos. Eso suele ser suficientemente bueno, y es un objetivo perfectamente razonable.

## HATEOAS (Nivel 3)

**HATEOAS** = *Hypermedia As The Engine Of Application State*. La idea: una response incluye **links** que le dicen al client qué acciones están disponibles a continuación, de modo que el client navega la API siguiendo links en lugar de hardcodear URLs — como un humano que sigue links en una página web en lugar de memorizar cada 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" }
  }
}
```

Como el order está `pending`, el server ofrece los links `pay` y `cancel`. Una vez pagado, esos links desaparecen y podría aparecer un link `refund` — **el server dirige las transiciones de estado**, y el client solo sigue los links que se le dan.

## Por qué es raro

La promesa es el desacoplamiento: los clients no hardcodean URLs, así que el server puede reestructurarlas libremente. En la práctica la mayoría de los clients hardcodean de todos modos, HATEOAS añade complejidad real, y los formatos nunca se estandarizaron del todo (HAL, JSON:API, Siren compiten todos). La recompensa rara vez justifica el coste.

## Por qué es importante

Esta es una pregunta senior clásica porque separa a quienes **entienden REST tal como se definió originalmente** de quienes usan "REST" laxamente para significar "JSON sobre HTTP". La idea valiosa no es recitar los cuatro niveles — es el juicio de decir que el **Nivel 2 es el punto dulce pragmático** mientras se sabe que el REST verdadero (la definición de Fielding) *requiere* HATEOAS, y ser capaz de explicar *por qué la industria en su mayoría lo ignora*: el beneficio de desacoplamiento es real pero rara vez se materializa porque los clients hardcodean URLs igualmente, y la complejidad añadida más los formatos de hypermedia rivales no compensan para APIs típicas. Demostrar que sabes qué *es* HATEOAS, poder mostrar un ejemplo concreto de links dirigidos por el estado, y poder argumentar honestamente sobre el coste/beneficio — en lugar de insistir dogmáticamente en que toda API debe ser Nivel 3 — es exactamente el juicio equilibrado y basado en la experiencia que los entrevistadores buscan.

Los cuatro niveles

HATEOAS (Nivel 3)

Por qué es raro

Por qué es importante

Preguntas relacionadas