Fundamentos de REST
Este artículo es una definición de conceptos sobre REST, incluyendo preguntas de examen, ejemplo práctico y etiquetas.
De un vistazo
REST es un estilo arquitectónico para sistemas distribuidos basados en HTTP: los recursos se direccionan mediante URIs, se manipulan a través de métodos y se transmiten en forma de representaciones. Objetivo: acoplamiento débil, escalabilidad, cacheo.
Descripción técnica compacta
REST define seis restricciones:
- Cliente-Servidor
- Ausencia de estado
- Capacidad de cacheo
- Interfaz uniforme
- Capas
- Opcionalmente, Code on Demand
Los recursos son objetos de negocio (por ejemplo, /orders/42). Las representaciones transportan estado (JSON/XML), negociadas mediante Accept y Content-Type.
Semántica de métodos:
- GET: seguro e idempotente
- POST: no idempotente
- PUT: idempotente
- PATCH: no necesariamente idempotente
- DELETE: idempotente
Los códigos de estado señalan éxitos o errores (200/201/204/400/401/403/404/409/500). HATEOAS utiliza enlaces en representaciones para flujos “descubribles”. El cacheo usa Cache-Control, ETag, If-None-Match.
Puntos clave relevantes para examen
- Diseño de URIs orientado a recursos (sin verbos en la ruta)
- Semántica segura e idempotente de métodos
- Códigos de estado correctos (Location en 201)
- Idempotency Key para POST (si es necesario)
- Seguridad: TLS, OAuth/OIDC/JWT, CORS, Rate Limiting
- Eficiencia: acoplamiento débil
- Documentación: OpenAPI + catálogo de errores
Componentes clave
- Recurso + Diseño de URIs
- Representaciones + Tipos de medios
- Semántica de métodos
- Códigos de estado + Encabezados
- Content Negotiation
- Cacheo (ETag)
- Seguridad
- Versionamiento
- Observabilidad
- Tests (Contract/API)
Ejemplo práctico (Orders + HATEOAS)
{
"id": 42,
"status": "created",
"links": [
{ "rel": "self", "href": "/orders/42" },
{ "rel": "confirm", "method": "POST", "href": "/orders/42/confirm" }
]
}
Ventajas y desventajas
Ventajas
- Interoperabilidad a través de estándares
- Acoplamiento débil
- Buena escalabilidad mediante ausencia de estado
- Cacheo eficiente
Desventajas
- Posibilidad de overfetching/underfetching
- Los procesos de escritura complejos requieren estrategias de idempotencia
- HATEOAS rara vez se utiliza de forma consistente
Preguntas típicas de examen (con respuesta breve)
- ¿Cuáles son las restricciones de REST? Cliente-Servidor, Stateless, Cache, Interfaz uniforme, Capas, opcionalmente Code on Demand.
- ¿PUT vs PATCH respecto a idempotencia? PUT es idempotente, PATCH no automáticamente.
- ¿Cómo funcionan ETag y las solicitudes condicionales?
El cliente envía
If-None-Match, el servidor responde con 304 o entrega un nuevo cuerpo.
Respuesta libre
REST es más que “JSON sobre HTTP”: las restricciones y la semántica de métodos son decisivas. Objetos de error limpios, versionamiento y observabilidad hacen que las APIs sean mantenibles.
Estrategia de aprendizaje
- Analiza APIs públicas y asigna restricciones.
- Diseña un modelo de recursos (URIs/métodos/códigos de estado).
- Practica una tabla de semántica de métodos (seguro/idempotente).
- Evita verbos en la ruta.
Fuentes más importantes
- https://roy.gbiv.com/untangled
- https://www.rfc-editor.org/rfc/rfc9110
- https://learn.microsoft.com/azure/architecture/best-practices/api-design



