La comunicación entre cliente y servidor sigue las reglas definidas en la especificación de la API.
REST se inventó para estandarizar estas reglas.
REST es un estilo de comunicación entre cliente y servidor.
REST API
Representational State Transfer
Características clave de REST
Arquitectura cliente-servidor
El cliente envía solicitudes al servidor, que se encarga del procesamiento y del almacenamiento de datos.
La separación de responsabilidades permite desarrollar y escalar cliente y servidor de forma independiente.
Sin estado
Cada solicitud contiene toda la información necesaria para que el servidor la procese, por ejemplo un token JWT de autorización con información del cliente.
El enfoque contrario consiste en almacenar sesiones de cliente en el servidor.
Cacheable
El cliente cachea respuestas del servidor para evitar solicitudes repetidas cuando los datos no han cambiado.
El almacenamiento temporal de datos en el cliente reduce la carga del servidor y mejora el rendimiento.
Interfaz uniforme
Los recursos se representan con direcciones URL consistentes.
La URL contiene el nombre del recurso, y la acción se determina por el método HTTP.
Por ejemplo,
GET /cookies/1
Interfaz uniforme
El endpoint se nombra según el recurso sobre el que se opera, en plural:
/cookies — recurso cookie
El método HTTP corresponde a la operación realizada sobre el recurso:
| Método | Ejemplo | Descripción |
|---|---|---|
| GET | GET /cookies/1 |
Obtener una cookie |
| POST | POST /cookies |
Crear una cookie |
| PUT | PUT /cookies/1 |
Reemplazar una cookie |
| PATCH | PATCH /cookies/1 |
Actualizar una cookie |
| DELETE | DELETE /cookies/1 |
Eliminar una cookie |
El código de respuesta HTTP refleja el resultado de la solicitud:
| Código | Significado |
|---|---|
200 OK |
Solicitud exitosa |
201 Created |
Recurso creado |
204 No Content |
Éxito, sin contenido en la respuesta |
400 Bad Request |
Solicitud incorrecta |
401 Unauthorized |
Autenticación fallida |
403 Forbidden |
Acceso al recurso prohibido |
404 Not Found |
Recurso no encontrado |
500 Internal Server Error |
Error del servidor |
Idempotencia: repetir la misma operación produce el mismo resultado.
Métodos HTTP idempotentes:
- GET la solicitud nunca debe cambiar el estado del servidor.
- PUT y DELETE las solicitudes no deben cambiar el estado del servidor si se repiten.
Ejemplo de requisitos de REST API
Gestión del almacenamiento de cookies
El servicio permite obtener, agregar y actualizar cookies.
-
Obtener todas las cookies.
GET /cookies
Ejemplo de respuesta
200 OK [ { "id": 1, "flavor": "vanilla", "size": "medium", "wish": "May your day be sweet!" }, { "id": 2, "flavor": "chocolate", "size": "small", "wish": "Success!" }, { "id": 3, "flavor": "cinnamon", "size": "large", "wish": "Warmth and comfort!" } ] -
Obtener una cookie por identificador.
GET /cookies/{id}
Ejemplo de respuesta
200 OK { "id": 1, "flavor": "vanilla", "size": "medium", "wish": "May your day be sweet!" } -
Agregar una cookie.
POST /cookies
Solicitud en formato JSON:
Campo Tipo Obligatorio Restricciones flavor string + chocolate, vanilla, cinnamon size string + small, medium, large wish string + de 1 a 255 caracteres Ejemplo de respuesta
201 Created { "id": 1, "flavor": "vanilla", "size": "medium", "wish": "May your day be sweet!" }Si el almacenamiento está lleno:
507 Insufficient Storagecon el mensaje “Storage is full”. -
Actualizar una cookie.
PUT /cookies/{id}
Solicitud en formato JSON:
Campo Tipo Obligatorio Restricciones flavor string + chocolate, vanilla, cinnamon size string + small, medium, large Ejemplo de respuesta
200 OK { "id": 1, "flavor": "vanilla", "size": "medium", "wish": "May your day be sweet!" } -
Actualizar parcialmente una cookie.
PATCH /cookies/{id}
Solicitud en formato JSON:
Campo Tipo Obligatorio Restricciones flavor string - chocolate, vanilla, cinnamon size string - small, medium, large Ejemplo de respuesta
204 No Content
Formato de datos: application/json
Todas las solicitudes API deben enviarse con un token JWT en el encabezado Authorization.
Tarea
Уровень повышен!
