REST (Representational State Transfer) es el estilo arquitectónico más extendido para diseñar APIs sobre HTTP. Lo formalizó Roy Fielding en su tesis doctoral del año 2000 y propone tratar todo lo que la API expone como recursos —usuarios, pedidos, facturas— identificados por URLs, manipulables mediante los verbos HTTP estándar (GET, POST, PUT, PATCH, DELETE) y representados en un formato negociable, normalmente JSON.
REST se apoya en propiedades del propio HTTP: códigos de estado para indicar resultado (200, 201, 400, 401, 404, 422, 500), cabeceras para autenticación y caché (ETag, Cache-Control), idempotencia para reintentos seguros y verbos seguros para permitir caching transparente. Es un protocolo sin estado: cada petición lleva toda la información necesaria para que el servidor la procese, lo que simplifica el escalado horizontal y la operación detrás de balanceadores.
En la práctica la mayoría de "APIs REST" son pragmáticas, no estrictamente RESTful: rara vez aplican HATEOAS de forma completa, suelen combinar paginación, filtros, sub-recursos y endpoints de acción que no encajan en un modelo CRUD puro. Para mantener calidad, lo importante es documentar el contrato con OpenAPI/Swagger, versionar la API (path o header), proteger los endpoints con OAuth 2.0 o JWT y observar latencias y errores con métricas y trazas.
En 10Code construimos APIs REST a diario sobre Laravel, Node y Python: validación de payloads con DTOs y schemas (Zod, Pydantic, FormRequest), autenticación con Sanctum, Passport u Okta, documentación OpenAPI generada del código, paginación cursor-based y tests de contrato. Cuando un caso pide algo distinto —móvil con consultas anidadas, streaming, RPC— evaluamos GraphQL o gRPC; el resto del tiempo, REST sigue siendo la opción más simple y robusta.
En 10Code llevamos más de una década aplicando estas tecnologías a productos reales. Si quieres comentarnos tu caso, escríbenos y te respondemos personalmente.
Hablar con un ingeniero