Skip to content
IRC-CodingIRC-Coding
RESTHATEOASETagCachingOpenAPI

REST: Constraints, HATEOAS, Caching y Diseño

REST explicado: 6 constraints, recursos/URIs, semántica de métodos, códigos de estado, HATEOAS, caching con ETag.

S

schutzgeist

2 min read
REST: Constraints, HATEOAS, Caching y Diseño

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

  1. Recurso + Diseño de URIs
  2. Representaciones + Tipos de medios
  3. Semántica de métodos
  4. Códigos de estado + Encabezados
  5. Content Negotiation
  6. Cacheo (ETag)
  7. Seguridad
  8. Versionamiento
  9. Observabilidad
  10. 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)

  1. ¿Cuáles son las restricciones de REST? Cliente-Servidor, Stateless, Cache, Interfaz uniforme, Capas, opcionalmente Code on Demand.
  2. ¿PUT vs PATCH respecto a idempotencia? PUT es idempotente, PATCH no automáticamente.
  3. ¿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

  1. Analiza APIs públicas y asigna restricciones.
  2. Diseña un modelo de recursos (URIs/métodos/códigos de estado).
  3. Practica una tabla de semántica de métodos (seguro/idempotente).
  4. Evita verbos en la ruta.

Fuentes más importantes

  1. https://roy.gbiv.com/untangled
  2. https://www.rfc-editor.org/rfc/rfc9110
  3. https://learn.microsoft.com/azure/architecture/best-practices/api-design
Volver al blog
Share:

Nächster Artikel in Arquitectura de Software

Weiterlesen
Schichtenmodell: MVC y n-Tier explicado

Entradas relacionadas