Definición
REST es un estilo arquitectónico propuesto por Roy Fielding en el año 2000 en su tesis doctoral. Su objetivo es definir cómo interactúan los sistemas distribuidos (por ejemplo, aplicaciones cliente-servidor) utilizando estándares de la web, especialmente HTTP.
Principios fundamentales de REST
· Arquitectura cliente-servidor: separación de responsabilidades → escalabilidad.
· Comunicación sin estado (Stateless): cada petición HTTP incluye toda la información necesaria.
· Cacheabilidad: las respuestas deben indicar si son cacheables o no.
· Interfaz uniforme: manipulación estándar de recursos mediante URI y representaciones.
· Recursos identificados por URI: cada recurso se representa con una dirección única.
· Representación de recursos: JSON, XML, etc.
· Sistema en capas: múltiples capas como balanceadores o cachés.
· Código bajo demanda (opcional): envío de código ejecutable al cliente.
Operaciones estándar (Métodos HTTP)
Método |
Acción |
Ejemplo en URI |
Descripción |
GET |
Leer |
/api/usuarios |
Obtiene todos los usuarios |
GET |
Leer |
/api/usuarios/5 |
Obtiene el usuario con id=5 |
POST |
Crear |
/api/usuarios |
Crea un nuevo usuario |
PUT |
Reemplazar |
/api/usuarios/5 |
Actualiza completamente el usuario 5 |
PATCH |
Modificar |
/api/usuarios/5 |
Actualiza parcialmente el usuario 5 |
DELETE |
Eliminar |
/api/usuarios/5 |
Elimina el usuario con id=5 |
Ejemplo de API REST
1. Obtener todos los usuarios: GET /api/usuarios
[ { "id": 1, "nombre": "Ana" }, { "id": 2, "nombre": "Luis" } ]
2. Crear un nuevo usuario: POST /api/usuarios
{ "nombre": "Emilio", "email": "emilio@example.com" }
3. Actualizar usuario existente: PUT /api/usuarios/3
{ "nombre": "Emilio J. Gómez", "email": "emiliojg@example.com" }
4. Eliminar un usuario: DELETE /api/usuarios/3
Ventajas de REST
· Simple de implementar y entender.
· Escalable y ampliamente usado en APIs modernas.
· Compatible con cualquier cliente que pueda usar HTTP.
· Uso de caché para optimizar rendimiento.
· Separación clara entre cliente y servidor.
Desventajas de REST
· No es adecuado para comunicación en tiempo real (mejor usar WebSockets).
· Al ser stateless, cada petición debe repetir información.
· No define estándares estrictos (cada API puede variar en su implementación).
· Con datos muy complejos, puede ser menos eficiente que GraphQL.
REST vs. Otros modelos
· REST → Basado en recursos y HTTP, simple y universal.
· SOAP → Protocolo más pesado, basado en XML, con contratos estrictos.
· GraphQL → Más flexible, permite pedir exactamente los datos que necesitas.
· gRPC → Más eficiente en alto rendimiento, usa HTTP/2 y Protobuf.