REST

Qué es

REST significa Representational State Transfer. Es un estilo arquitectónico descrito por Roy Fielding en su tesis doctoral (Universidad de California, Irvine, 2000). En la práctica se usa para diseñar APIs web sobre HTTP de forma que cualquier cliente (web, móvil, otro servidor) pueda comunicarse con el servidor de forma predecible.

Una API que sigue estos principios se llama RESTful o API REST.

Las 6 restricciones de REST

Restricción	Descripción
Sin estado (Stateless)	Cada petición contiene toda la información necesaria — el servidor no “recuerda” peticiones anteriores
Cliente-Servidor	El cliente y el servidor son independientes — el cliente no sabe cómo funciona el backend
Interfaz uniforme	Recursos con URLs consistentes y métodos HTTP estándar
Caché	Las respuestas pueden indicar si pueden guardarse en caché
Sistema por capas	El cliente no sabe si hay proxies o balanceadores entre ellos
Código bajo demanda (opcional)	El servidor puede enviar código ejecutable al cliente

Los Métodos HTTP en REST

Método	Operación	Ejemplo
GET	Obtener datos	`GET /usuarios/123` → devuelve el usuario 123
POST	Crear nuevo recurso	`POST /usuarios` → crea un usuario nuevo
PUT	Actualizar completamente	`PUT /usuarios/123` → reemplaza el usuario 123
PATCH	Actualizar parcialmente	`PATCH /usuarios/123` → actualiza solo el email
DELETE	Eliminar	`DELETE /usuarios/123` → borra el usuario 123

Diseño de URLs RESTful

Una API REST bien diseñada usa sustantivos (no verbos) en las URLs:

✅ RESTful:
GET    /productos          → lista de productos
GET    /productos/42       → producto con ID 42
POST   /productos          → crear producto
PUT    /productos/42       → actualizar producto 42
DELETE /productos/42       → eliminar producto 42

❌ No RESTful:
GET /getProductos
GET /obtenerProducto?id=42
POST /crearProducto
GET /borrarProducto?id=42

Respuestas y Códigos HTTP

Las APIs REST usan los códigos de estado HTTP estándar:

Código	Significado	Cuándo se usa
200 OK	Éxito	GET o PUT exitoso
201 Created	Recurso creado	POST exitoso
204 No Content	Éxito sin contenido	DELETE exitoso
400 Bad Request	Petición inválida	Datos faltantes o incorrectos
401 Unauthorized	No autenticado	Sin token o token inválido
403 Forbidden	Sin permisos	Token válido pero sin acceso
404 Not Found	No existe	Recurso no encontrado
500 Internal Server Error	Error del servidor	Bug interno

Ejemplo real de respuesta REST

// GET /pedidos/789
{
  "id": 789,
  "estado": "en_preparacion",
  "cliente": {
    "id": 123,
    "nombre": "Ana García"
  },
  "items": [
    { "producto": "Laptop", "cantidad": 1, "precio": 1299.99 }
  ],
  "total": 1299.99,
  "creadoEn": "2026-03-10T14:30:00Z"
}

REST vs otras alternativas

Tecnología	Caso de uso ideal	Diferencia clave
REST	La mayoría de APIs web	Simple, estándar, amplio soporte
GraphQL	APIs con datos complejos y variables	El cliente elige exactamente qué campos recibe
gRPC	Comunicación interna entre microservicios	Generalmente más eficiente (HTTP/2 + Protocol Buffers), contratos tipados, menos legible
SOAP	Sistemas legacy o empresariales	Protocolo XML más verboso y estricto

Por qué importa

Cuando un equipo de desarrollo dice “construiremos una API REST”, están tomando decisiones que afectan:

La facilidad de integrar el sistema con otras herramientas
El rendimiento y escalabilidad
La documentación y mantenibilidad
La experiencia de desarrollo para quien consume la API

Una API REST bien diseñada dura años y puede ser consumida por web, móvil, y otros sistemas sin cambios.

Términos relacionados

API - El concepto general; REST es el estilo de diseño más popular
Endpoint - Cada URL de una API REST es un endpoint
JWT - Formato de token muy usado para autenticar peticiones en APIs REST
Microservices - Arquitectura donde cada servicio expone su propia API REST

Recursos adicionales:

REST API Tutorial - Guía práctica
MDN - Códigos de estado HTTP - Referencia de todos los códigos HTTP

Pronunciación