Principios de Diseño RESTful
Este artículo es una aclaración de conceptos sobre principios de diseño RESTful, incluidas preguntas de evaluación y etiquetas.
En Resumen
REST es un enfoque arquitectónico para APIs basado en HTTP que se destaca por sus métodos claramente definidos, recursos, códigos de estado y ausencia de estado.
Descripción Técnica Concisa
REST es un protocolo ligero basado en HTTP para el intercambio de recursos entre cliente y servidor. Utiliza los métodos HTTP: GET (lectura), POST (creación), PUT (reemplazo), DELETE (eliminación), PATCH (actualización parcial). REST sigue el principio de statelessness, lo que significa que cada solicitud debe contener toda la información necesaria y el servidor no almacena datos de sesión. La idempotencia juega un papel importante: GET, PUT y DELETE son idempotentes (la ejecución múltiple tiene el mismo efecto), mientras que POST y PATCH no lo son. REST utiliza códigos de estado estandarizados (por ejemplo, 200 OK, 201 Created, 404 Not Found, 500 Server Error) para comunicar resultados.
Puntos Clave para Evaluación
- GET, POST, PUT, DELETE, PATCH: métodos HTTP para CRUD
- REST es sin estado, no hay seguimiento de sesión en el servidor
- Idempotencia: solicitudes repetidas solo actúan una vez (por ejemplo, en PUT)
- URIs orientadas a recursos, por ejemplo /api/users/123
- Uso de códigos de estado HTTP (200, 201, 404, 500, etc.)
- PATCH actualiza solo partes de un objeto
- Aspectos de seguridad: autenticación por token, HTTPS, CORS
- Documentación de interfaces con OpenAPI o Swagger
Componentes Principales
- Métodos HTTP (GET, POST, PUT, DELETE, PATCH)
- Convenciones de URI (basadas en recursos)
- Códigos de estado (2xx, 4xx, 5xx)
- Conformidad REST (Richardson Maturity Model)
- Reglas de idempotencia
- Arquitectura sin estado
- Content Negotiation (encabezados Accept/Content-Type)
- JSON/XML como formatos de datos
- Autenticación (Bearer Token, API Keys)
- Documentación OpenAPI/Swagger
Ejemplo Práctico
// Ejemplo: REST-API para gestión de usuarios
GET /users → Lista todos los usuarios
POST /users → Crear nuevo usuario
GET /users/1 → Mostrar usuario con ID 1
PUT /users/1 → Reemplazar usuario completamente
PATCH /users/1 → Actualizar solo campos específicos
DELETE /users/1 → Eliminar usuario
Explicación: Cada método corresponde a una acción claramente definida sobre un recurso. La URI permanece constante, el método cambia la semántica.
Ventajas y Desventajas
Ventajas
- Simple, fácil de entender
- Usa protocolos estándar (HTTP)
- Independiente de plataforma e idioma
- Escalable
Desventajas
- Sin gestión de sesiones integrada
- Puede ser ineficiente con muchas llamadas API
- Sin estandarización para operaciones complejas
Preguntas Típicas de Evaluación (con respuesta breve)
- ¿“Sin estado” en REST? El servidor no almacena datos de sesión. Cada solicitud debe ser completa en sí misma.
- ¿Métodos HTTP idempotentes? GET, PUT, DELETE.
- ¿Diferencia entre PUT y PATCH? PUT reemplaza un objeto completamente, PATCH cambia solo campos específicos.
- ¿Código de estado 201? Recurso creado exitosamente.
- ¿REST vs. SOAP? REST es ligero, utiliza HTTP directamente, SOAP es basado en XML y pesado.
- ¿Cómo direccionar un recurso? Mediante URI, por ejemplo /users/123.
- ¿Medidas de seguridad para REST-APIs? HTTPS, autenticación por token, control de acceso.
- ¿Por qué es importante la idempotencia? Los reintentos durante fallos de red no tienen consecuencias no deseadas.