REST

REST no es un protocolo ni un estándar. Es un estilo arquitectónico pensado para sistemas hipermedia repartidos por la red, y se formuló en una tesis doctoral que analizaba por qué la web había funcionado tan bien. No lo publica ningún organismo, no hay un documento normativo que valide un servicio como REST y no tiene ninguna relación con SOAP.

De ahí la distinción de vocabulario que se pregunta: REST es la parte teórica, el conjunto de restricciones. Una API RESTful es la realización concreta de esas ideas sobre HTTP, es decir, el interfaz por el que dos sistemas intercambian información a través de la red respetando ese estilo.

REST es un estilo y SOAP es un protocolo. No se comparan como dos protocolos rivales: se comparan un modo de organizar el interfaz y una especificación de mensajes.

Un servicio se considera REST cuando cumple una serie de restricciones. Las cuatro primeras son las que se citan siempre; las tres últimas completan la lista original y también caen.

• Cliente/servidor: los papeles están separados y cada lado evoluciona por su cuenta.
• Sin estado: el servidor no guarda nada entre una petición y la siguiente. Es la restricción más característica.
• Interfaz uniforme: operaciones bien definidas y las mismas para todos, apoyadas en los verbos HTTP aplicados a recursos.
• Identificación de recursos: cada recurso tiene su URI, y las entidades que se exponen son entidades de negocio (un alumno, un tema, un intento), no funciones.
• Caché: las respuestas indican si se pueden almacenar, lo que evita repetir peticiones idénticas. (Ampliación de esta plataforma.)
• Sistema en capas: quien llama no sabe si le responde el servidor final o un intermediario, lo que permite meter balanceadores y pasarelas por el camino. (Ampliación de esta plataforma.)
• Código bajo demanda: el servidor puede enviar código ejecutable al cliente. Es la única restricción opcional. (Ampliación de esta plataforma.)

La restricción de sistema en capas es interesante porque enlaza este tema con su primera mitad: REST no solo tolera una arquitectura multicapa, la asume como parte del estilo.

En REST todo gira alrededor del recurso: una cosa del dominio que se puede nombrar. La URI dice cuál es el recurso y el verbo HTTP dice qué se quiere hacer con él. Por eso la URI se construye con sustantivos y nunca con verbos: la acción ya la lleva el método de la petición.

GET /api/alumnos/482/intentos?tema=servicios-web HTTP/1.1
Host: api.llegandoalcorte.com
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...


HTTP/1.1 200 OK
Content-Type: application/json

{
  "alumno": 482,
  "tema": "servicios-web",
  "intentos": [
    { "id": 9137, "fecha": "2026-08-14", "aciertos": 42, "preguntas": 50 },
    { "id": 9422, "fecha": "2026-08-15", "aciertos": 47, "preguntas": 50 }
  ]
}

Seguro significa que no altera nada; idempotente, que repetir la misma petición deja el sistema igual que si se hubiera hecho una vez. POST es el que no es ninguna de las dos cosas, y por eso reenviar un formulario duplica el registro.

Una API REST no inventa su propio sistema de errores: reutiliza los códigos de estado de HTTP, y eso forma parte del interfaz uniforme. El primer dígito ya dice de quién es el problema.

Dos parejas que conviene tener claras. Un POST que crea un recurso debería responder 201 y no 200. Y 401 no es lo mismo que 403: el 401 dice «no sé quién eres», el 403 dice «sé quién eres y no puedes».

Que REST sea sin estado significa que el servidor no guarda información sobre la conversación entre una petición y la siguiente. Cada petición llega completa: lleva todo lo que hace falta para entenderla y atenderla, incluida la identidad de quien la hace. El servidor no recuerda que hace un momento ese mismo cliente se autenticó.

Ojo con lo que no significa. El servidor sí guarda estado de los recursos, que para eso está la base de datos: los intentos de un alumno siguen ahí mañana. Lo que no guarda es estado de sesión. Por eso, cuando la API usa testigos, el cliente tiene que enviar el suyo en cada llamada.

• A favor: cualquier servidor del grupo puede atender cualquier petición, así que escalar es solo añadir máquinas detrás de un balanceador.
• A favor: no hay sesiones que replicar ni que expirar, y la caída de un servidor no tira a los usuarios que estaban atendidos por él.
• En contra: cada petición viaja con más información encima, porque tiene que repetir el contexto.
• En contra: el estado de la conversación pasa a ser responsabilidad del cliente.

Sin estado se refiere a la sesión, no a los datos. Un servicio REST puede tener una base de datos enorme y seguir siendo perfectamente sin estado.

HATEOAS son las siglas de Hypermedia As The Engine Of Application State. La idea es que la respuesta no se limite a los datos: que incluya también los enlaces a lo que se puede hacer a continuación, igual que una página web incluye sus enlaces. El cliente no tiene que conocer de antemano todas las direcciones de la API, las descubre navegando.

En la práctica, al pedir un alumno el servicio no devuelve todos sus datos ni todo lo relacionado, sino lo mínimo más una lista de enlaces a los recursos asociados: sus intentos, sus preguntas falladas, su matrícula. La señal de que una API aplica HATEOAS es justamente que sus respuestas traen una sección de enlaces.

{
  "id": 482,
  "nombre": "Alumno de ejemplo",
  "plan": "largo",
  "enlaces": [
    { "rel": "intentos", "href": "/api/alumnos/482/intentos", "metodo": "GET" },
    { "rel": "falladas", "href": "/api/alumnos/482/falladas", "metodo": "GET" },
    { "rel": "baja", "href": "/api/alumnos/482", "metodo": "DELETE" }
  ]
}

HATEOAS es la restricción de REST que menos se cumple en las APIs reales, y precisamente por eso es la que más se pregunta.