La mayoría de los desarrolladores creen saber qué es una API RESTful, pero en realidad solo han seguido buenas prácticas del sector y leído mucha documentación sin comprender el modelo original. REST no es un interfaz HTTP, sino un estilo arquitectónico definido por Roy Fielding en su tesis doctoral de 2000, que impone seis restricciones: arquitectura cliente-servidor, ausencia de estado en el servidor, respuestas cacheables de forma explícita, sistema por capas, interfaz uniforme y, opcionalmente, código bajo demanda. En la práctica, el uso popular ha acabado llamando REST a cualquier API HTTP que devuelve JSON, lo que motivó la queja de Fielding en su artículo de 2008 "REST APIs must be hypertext-driven". El Modelo de Madurez de Richardson cuantifica esa distancia en cuatro niveles: desde un único endpoint RPC (nivel 0) hasta la inclusión de hypermedia (nivel 3). Este artículo se centra en el nivel 3, el verdadero RESTful, donde la API se vuelve predecible, estandarizada y autodescriptiva: con solo la URL base el cliente puede explorar cada recurso sin necesidad de documentación externa. El concepto clave es HATEOAS (Hypermedia as the Engine of Application State), que permite descubrir recursos dinámicamente mediante enlaces en las respuestas, normalmente bajo una clave _links, usando plantillas URI (RFC 6570) cuando los endpoints son parametrizados. Las seis reglas derivadas de Fielding son: no depender de un único protocolo, no reinventar el protocolo (usar GET, POST, PUT, PATCH, DELETE y los códigos de estado correctos), centrarse en los media types en lugar de en las URI (definiendo tipos como application/vnd.myshop.product+json), no asumir estructuras de URI en el cliente, evitar exponer "tipos" de recursos en la jerarquía y apostar por la hypermedia para guiar la navegación. Aplicarlas convierte la API en un sistema mantenible, flexible y portable entre protocolos.
Noticias agregadas con IA