Skip to content
IRC-CodingIRC-Coding
RESTHTTPCódigos de estadoIdempotenciaStatelessOpenAPI

Principios de diseño RESTful: HTTP y mejores prácticas

Domina el diseño de APIs RESTful: métodos HTTP, códigos de estado, idempotencia, statelessness y seguridad con HTTPS y tokens.

S

schutzgeist

2 min read
Principios de diseño RESTful: HTTP y mejores prácticas

Principios de Diseño RESTful

Este artículo es una explicación de conceptos sobre principios de diseño RESTful, incluyendo preguntas de examen, puntos clave y etiquetas.

En Pocas Palabras

REST (Representational State Transfer) es un enfoque arquitectónico para APIs basadas en HTTP: métodos claros, URIs de recursos, códigos de estado y ausencia de estado.

Descripción Técnica Compacta

REST utiliza métodos HTTP para CRUD:

  • GET: leer
  • POST: crear
  • PUT: reemplazar completamente
  • PATCH: modificar parcialmente
  • DELETE: eliminar

REST sigue el principio de ausencia de estado: cada solicitud contiene toda la información necesaria; el servidor no almacena estado de sesión.

La idempotencia es importante para reintentos:

  • idempotente: GET, PUT, DELETE
  • no necesariamente idempotente: POST, PATCH

Los resultados se comunican mediante códigos de estado (por ejemplo, 200, 201, 404, 500). Los formatos de datos comunes son JSON/XML.

Puntos Clave Relevantes para Examen

  • Métodos HTTP para CRUD
  • REST es sin estado
  • Idempotencia: las repeticiones no deben duplicar efectos secundarios
  • URIs de recursos, por ejemplo /api/users/123
  • Códigos de estado (200, 201, 404, 500) (relevante para IHK)
  • PATCH modifica solo campos parciales
  • Seguridad: HTTPS, autenticación por token, CORS
  • Documentación: OpenAPI/Swagger (requisito de documentación)

Componentes Principales

  1. Métodos HTTP
  2. Convenciones de URI de recursos
  3. Códigos de estado (2xx/4xx/5xx)
  4. Conformidad REST (Richardson)
  5. Reglas de idempotencia
  6. Ausencia de estado
  7. Content Negotiation (Accept/Content-Type)
  8. JSON/XML
  9. Autenticación (Bearer/API-Key)
  10. OpenAPI/Swagger

Ejemplo Práctico (API de Usuarios)

GET /users
POST /users
GET /users/1
PUT /users/1
PATCH /users/1
DELETE /users/1

Ventajas y Desventajas

Ventajas

  • Simple, fácil de entender
  • Protocolo estándar (HTTP)
  • Independiente de plataforma y lenguaje
  • Escalable

Desventajas

  • Sin gestión de sesiones integrada
  • Puede volverse “chatty” (muchas solicitudes)
  • Para operaciones complejas se necesita un modelado limpio

Preguntas Típicas de Examen (con Respuesta Corta)

  1. ¿Qué significa sin estado? El servidor no almacena estado de sesión; la solicitud debe ser completa.
  2. ¿Cuáles son los métodos idempotentes? GET, PUT, DELETE.
  3. ¿PUT vs PATCH? PUT reemplaza completamente, PATCH solo campos parciales.
  4. ¿Qué significa 201? La recurso fue creada.

Respuesta Libre

REST es la columna vertebral de las APIs web modernas. En exámenes y proyectos, debes documentar los endpoints de forma clara, elegir los métodos correctamente y aplicar códigos de estado apropiadamente.

Estrategia de Aprendizaje

  1. Prueba la API con Postman/curl.
  2. Construye una mini-API con rutas CRUD.
  3. Memoriza métodos, códigos de estado e idempotencia.
  4. Usa PUT/DELETE solo de forma idempotente.

Análisis del Tema

  • Núcleo: HTTP, diseño de URI, JSON
  • Desafíos: versionado, manejo de errores, autenticación
  • Seguridad: control de acceso, cifrado, CORS
  • Documentación: OpenAPI, ejemplos, catálogo de errores
  • Economía: la estandarización ahorra tiempo

Información Adicional

  1. https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design
  2. https://developer.mozilla.org/de/docs/Web/HTTP/Methods
  3. https://restfulapi.net/
  4. https://swagger.io/specification/
Volver al blog
Share:

Nächster Artikel in Arquitectura de Software

Weiterlesen
Principios RESTful: GET, POST, PUT, DELETE, PATCH

Entradas relacionadas