REST vs RESTful: diferencias reales que casi nadie explica bien
Introducción
En entrevistas técnicas, documentación y charlas es habitual escuchar “API REST” y “API RESTful” como si fueran sinónimos. No lo son.
La confusión no es solo semántica: lleva a APIs inconsistentes, difíciles de mantener y con comportamientos impredecibles para clientes humanos y máquinas.
Entender la diferencia no es postureo arquitectónico: es diseñar mejor.
Qué es REST (el concepto original)
REST (Representational State Transfer) no es un estándar, ni un protocolo, ni “usar JSON sobre HTTP”. Es un estilo arquitectónico definido por Roy Fielding.
Para que una arquitectura sea REST debe cumplir una serie de restricciones:
- Arquitectura cliente-servidor.
- Comunicación stateless.
- Capacidad de cacheo.
- Interfaz uniforme.
- Sistema en capas.
- (Opcional) Código bajo demanda.
Qué significa realmente que una API sea RESTful
Una API es RESTful cuando respeta de forma consistente los principios REST en su diseño y comportamiento.
REST es la teoría. RESTful es la aplicación práctica, con todas sus implicaciones.
REST vs RESTful vs “REST-like”
| Aspecto | REST (teoría) | RESTful | REST-like habitual |
|---|---|---|---|
| Modelo | Estilo arquitectónico | Implementación coherente | Convención informal |
| Recursos | Obligatorios | Bien definidos | Mezcla recursos y acciones |
| Métodos HTTP | Semánticos | Usados correctamente | POST para todo |
| Estado | Stateless | Stateless real | Estado implícito |
Qué NO es REST (errores comunes)
- Usar JSON o HTTP.
- Tener endpoints.
- Usar Spring Boot, Express o FastAPI.
- Exponer acciones como URLs.
Ejemplos incorrectos:
POST /login
POST /activarUsuario
GET /getAllProducts
Principios RESTful explicados con ejemplos
1. Recursos, no acciones
En REST todo es un recurso:
/usuarios/123
/productos/42
/pedidos/2024
La acción la define el método HTTP, no la URL.
2. Uso correcto de métodos HTTP
| Método | Uso correcto |
|---|---|
| GET | Obtener representación |
| POST | Crear nuevo recurso |
| PUT | Reemplazar recurso completo |
| PATCH | Modificar parcialmente |
| DELETE | Eliminar recurso |
3. Stateless (de verdad)
Cada petición debe ser autosuficiente. El servidor no debe recordar contexto entre llamadas.
Tokens, cabeceras y payloads contienen toda la información necesaria.
4. Respuestas predecibles y semánticas
No solo importa el cuerpo, también:
- Códigos HTTP correctos.
- Estructuras consistentes.
- Errores bien definidos.
Y HATEOAS… ¿es obligatorio?
Técnicamente, REST completo incluye HATEOAS. En la práctica, muchas APIs RESTful prescinden de él por complejidad.
No usar HATEOAS no invalida una API, pero sí la aleja del REST “puro”.
Checklist rápida
- ¿Tus URLs representan recursos?
- ¿Usas métodos HTTP con semántica correcta?
- ¿Cada request es stateless?
- ¿Tus respuestas son coherentes y predecibles?
- ¿Evitas exponer acciones en la URL?
Conclusión
REST no es enviar JSON ni seguir una moda. Es una forma concreta de pensar y diseñar APIs.
RESTful es aplicar esa filosofía con coherencia, sin dogmas pero con rigor, para construir sistemas claros, mantenibles y fáciles de consumir.