De REST a HATEOAS: Evolucionando las Interacciones Web

REST es un conjunto de principios arquitectónicos que define cómo las aplicaciones se comunican a través de la web. Se basa en un sistema sin estado, donde las solicitudes y respuestas son independientes y se comunica mediante estándares como HTTP. En REST, los datos y la funcionalidad son considerados recursos, y estos recursos son identificados y accedidos mediante URI (Uniform Resource Identifiers).

Las características más aceptadas que definene un api REST, son:

• Interfaz Uniforme: Para simplificar y desacoplar la arquitectura, REST impone una interfaz uniforme que desacopla al cliente de los detalles del servidor.
• Sin estado: Cada petición de un cliente contiene toda la información que el servidor necesita para procesarla. El servidor no retiene ninguna información de estado del cliente entre solicitudes. Esto hace que las aplicaciones REST sean más escalables y simplifica el diseño del servidor.
• Cacheable: Las respuestas deben definir claramente si son cacheables o no. Esto permite a los clientes almacenar respuestas para mejorar el rendimiento al evitar solicitudes repetidas.
• Sistema cliente/servidor: REST utiliza el modelo cliente/servidor estándar que separa al cliente (interfaz de usuario) del servidor (almacenamiento de datos). Esta separación permite que ambas partes evolucionen de forma independiente.
• Sin almacenamiento de estado en el servidor: Como mencionamos anteriormente, REST es sin estado. Esto significa que las sesiones del cliente se almacenan en el lado del cliente, y no en el servidor.
• Basado en protocolos estándar: Aunque REST puede ser usado con casi cualquier protocolo, casi siempre se utiliza con HTTP. Esto es beneficioso ya que simplifica la arquitectura y aprovecha las características propias del protocolo, como los métodos GET, POST, PUT y DELETE.
• Comunicación basada en recursos: En REST, los recursos (que pueden ser datos o servicios) están identificados por URIs, típicamente enlaces. Esto facilita la forma en que se accede a la información y cómo se representan las operaciones en estos recursos.

Una de las ventajas que aporta es la sencillez de acceso y dependencias a la hora de trabajar con recursos. Se reduce mucho la cantidad de funcionalidades que es necesario recordar (y los parámetros disponibles).

HATEOAS, que significa "Hypermedia as the Engine of Application State" (Hypermedia como Motor del Estado de la Aplicación), es uno de los principios centrales de REST que, cuando se aplica, permite que las aplicaciones cliente entiendan las posibles interacciones con una API solo a través de la información dinámica proporcionada en las respuestas del servidor.

HATEOAS es uno de los principios fundamentales de REST y se refiere al concepto de que una aplicación o cliente interactúa con un servicio web completamente a través de hypermedia proporcionada dinámicamente por las respuestas de las aplicaciones servidoras. Los beneficios incluyen:

• Descubrimiento: Un cliente puede descubrir dinámicamente las acciones disponibles. En lugar de tener un conjunto fijo de operaciones codificadas por adelantado, un cliente puede recibir en tiempo real las acciones que están disponibles para él en ese momento.
• Desacoplamiento: Gracias a HATEOAS, los clientes pueden evolucionar de forma independiente de los servidores, ya que se basan en la información dinámica proporcionada por el servidor para decidir las acciones a tomar.
• Auto-documentación: Los clientes pueden entender cómo interactuar con el recurso simplemente siguiendo los enlaces proporcionados.

Hay definido un Richardson Maturity Model que califica un API en función de su adherencia a las restricciones de la arquitectura REST.

• Nivel 0: The Swamp of POX (El Pantano de POX): Es el nivel más básico, donde una única URI y un único método (por lo general, POST) se utilizan para todo. Este nivel no se considera RESTful.
• Nivel 1: Resources (Recursos): Introduce múltiples URIs para identificar recursos individuales. Sin embargo, sigue usando un único método HTTP (por lo general, POST).
• Nivel 2: HTTP Verbs (Verbos HTTP) Implementa y utiliza adecuadamente los verbos HTTP (GET, POST, PUT, DELETE, etc.) para operaciones CRUD. También se hace uso de códigos de estado HTTP para indicar el éxito o fallo de una operación.
• Nivel 3: Hypermedia Controls (Controles de Hypermedia) Este es el nivel donde HATEOAS entra en juego. Las respuestas proporcionan información, a través de hypermedia, sobre las siguientes acciones posibles que un cliente puede realizar en la aplicación. Esto significa que el cliente puede navegar y descubrir funcionalidades dinámicamente, en lugar de tenerlas codificadas de antemano.

El avance hacia niveles de madurez más altos en la implementación de APIs, específicamente hacia el Nivel 3 con HATEOAS, ha encontrado resistencia entre muchos desarrolladores y organizaciones. Una de las principales razones es la percepción de complejidad adicional sin un valor inmediato evidente. Implementar HATEOAS requiere no solo diseñar URIs y métodos, sino también pensar en cómo la aplicación presenta y consume enlaces dinámicos, lo que puede llevar a un esfuerzo de diseño e implementación más significativo.

Además, muchos desarrolladores consideran que la auto-descubribilidad, una de las principales ventajas de HATEOAS, no es esencial para la mayoría de las aplicaciones. En muchos escenarios, los clientes que consumen la API están predefinidos o controlados, y no necesitan descubrir funcionalidades dinámicamente. Esto, sumado a la falta de herramientas estándar robustas para el consumo de APIs HATEOAS y a la necesidad de educar a los desarrolladores sobre este nivel adicional de madurez, ha frenado la adopción plena del Nivel 3 en muchas APIs "RESTful" en la práctica.