Front web + móvil
Un solo back-end alimenta varios clientes.
¿Qué es una API REST? Recursos, verbos HTTP y contratos
Una API REST es una interfaz web que expone recursos mediante HTTP, con URL estables, verbos (GET, POST, PUT, PATCH, DELETE) y representaciones —a menudo JSON—. Inspirada en el estilo de Roy Fielding, prioriza el servidor sin estado y una semántica HTTP clara. Es el contrato más habitual entre un front, una app móvil y un back-end de negocio.
En una frase
Una API REST hace hablar a clientes y servidores vía HTTP y recursos direccionables.
Para recordar
- Los recursos tienen URI; los verbos HTTP describen la acción sin inventar otro protocolo.
- El servidor no guarda sesión entre peticiones (stateless): cada llamada lleva el contexto necesario.
- JSON domina los payloads; los códigos de estado comunican el resultado.
- OpenAPI/Swagger documenta el contrato para equipos front, móvil y partners.
Ficha del término
- API REST
- REST API · API RESTful · API web REST
- Término en inglés
- REST API
- Dominio
- Desarrollo de software
- Categoría
- Integración
- Nivel
- Intermedio
¿Qué significa exactamente «API REST»?
REST (Representational State Transfer) no es un único estándar ISO, sino un estilo: identificación de recursos, manipulación vía representaciones, mensajes auto-descriptivos y, idealmente, hipermedia. En la práctica, «API REST» suele significar una API HTTP JSON bien estructurada, aunque no se cumplan todas las restricciones de Fielding.
Para una pyme, la API REST es la bisagra entre el sitio, la app, un ERP o un partner. Un mal diseño (verbos en la URL, sesiones pegajosas, errores opacos) encarece cada integración.
La seguridad (TLS, OAuth 2.0 / JWT, rate limiting) y el versionado (/v1) son parte del producto API tanto como los endpoints de negocio.
¿Cómo se diseña una API REST sólida?
- 01
Modelar recursos
Nombrar entidades de negocio (clientes, pedidos, facturas) y relaciones en lugar de acciones RPC dispersas.
- 02
Fijar el contrato
Esquemas de petición/respuesta, errores, paginación y filtros —idealmente en OpenAPI—.
- 03
Asegurar y observar
Autenticación, autorización, logs, latencia y cuotas.
- 04
Versionar y evolucionar
Cambios compatibles primero; breaking changes detrás de una versión mayor.
Ejemplo concreto de API REST
Un fabricante de Montreal expone GET /v1/orders/{id} y PATCH /v1/orders/{id}/status para que el portal del cliente y la app de repartidores compartan el mismo estado. Las respuestas JSON incluyen ETag; la app móvil evita recargar el pedido si nada cambió. Baján las consultas manuales de «¿dónde está mi pedido?».
¿Para qué sirve una API REST?
Integraciones con partners
Intercambio de catálogos, stock o leads con terceros.
Automatización interna
Scripts y herramientas consumen los mismos endpoints que el producto.
Microservicios
Comunicación síncrona entre servicios vía HTTP JSON.
Ventajas y límites de las API REST
- Ecosistema HTTP maduro (cachés, proxies, herramientas)
- URI y verbos legibles para los equipos
- Amplio soporte de clientes (navegadores, móviles, SDK)
- Documentación y pruebas más fáciles (OpenAPI, Postman)
- Over-fetch / under-fetch si los recursos están mal cortados
- Menos ideal para tiempo real que WebSocket o gRPC streaming
- El versionado exige disciplina
- «REST-washing»: muchas API HTTP no son realmente REST
¿En qué se diferencia REST de GraphQL?
| API REST | GraphQL | |
|---|---|---|
| Forma de la petición | Varios endpoints de recurso + verbos HTTP | Un endpoint; el cliente describe los campos |
| Caché HTTP | Natural en GET (URI, ETag) | Más complejo; a menudo caché de aplicación |
| Curva de aprendizaje | Baja si se conoce HTTP | Esquema, resolvers, herramientas dedicadas |
| Caso ideal | Contratos estables, integraciones clásicas | Clientes con necesidades de datos muy variables |
Por qué una API REST importa para una pyme quebequense
En cuanto un sitio, una app o un partner debe leer su stock, citas o clientes, necesita un contrato estable. Una API REST clara reduce el coste de cada integración, acelera alianzas y evita reconstruir la misma lógica en cada canal.
Preguntas frecuentes
¿REST es un protocolo?
No. Es un estilo arquitectónico sobre HTTP. Hablamos de API REST cuando se aplican (con más o menos rigor) sus restricciones.
¿Siempre tiene que ser JSON?
JSON es el valor por defecto de facto, pero REST admite otras representaciones vía negociación de contenido.
¿Cómo versionar sin romper clientes?
Prefiera añadidos compatibles; reserve /v2 para cambios incompatibles y publique fecha de fin de soporte.
¿REST sustituye a las colas de mensajes?
No. REST encaja en petición/respuesta síncrona; las colas (o eventos) siguen siendo útiles para desacoplar en asíncrono.
Términos relacionados
Fuentes y referencias
¿Necesita exponer datos a un sitio, app o partner? Diseñamos API REST documentadas, seguras y evolutivas.
Hablar de su API