«¿Qué son los tan populares RESTful Services? En vista de las numerosas definiciones e interpretaciones erróneas difundidas por la comunidad de TI, es fundamental que aclaremos los principios que guían el REST, sus características y desafíos.

REST (REpresentational State Transfer) se trata de un estilo arquitectónico orientado a los sistemas distribuidos y escalables, presentado por Roy Fielding en su tesis de doctorado en el año 2000. Se puede entender como estilo arquitectónico una serie de restricciones bien definidas (conocidas como «constraints«) que delimitan los elementos de una determinada arquitectura de software y sus interacciones.

Por lo tanto, el estilo REST proporciona un conjunto de restricciones arquitectónicas que, cuando se aplican en conjunto, mejoran la escalabilidad y el despliegue independiente de los componentes, la generalidad de las interfaces, la encapsulación de los sistemas legacy y las mejoras en la seguridad y el rendimiento. Por estos motivos, el REST (o al menos parte de él) ha sido ampliamente adoptado por diversas organizaciones como la principal forma de facilitar el acceso a sus servicios. El sitio web ProgrammableWeb nos ofrece una breve visión general de la diversidad de APIs alrededor del mundo que utilizan REST.

Este movimiento ha causado que muchos desarrolladores caractericen sus APIs basadas en HTTP RESTful. Sin embargo, según el propio Fielding, para que un servicio pueda llamarse RESTful, debe cumplir con todas las restricciones impuestas por REST y, sobre todo, estar orientado al hipertexto.

Por otro lado, tal vez porque aún no hay una recomendación/norma oficial de la industria, han surgido diferentes opiniones sobre cómo implementar el estilo correctamente y llegar al glorioso RESTful Service. A falta de una respuesta contundente a esta pregunta, es importante volver a examinar las principales constraints que deben seguirse al diseñar e implementar los servicios RESTful:

1. Arquitectura Cliente-Servidor: el objetivo principal de esta constraint es la separación de responsabilidades. Al separar los requisitos inherentes de la IU de las capas de negocio y de persistencia, se aumenta la portabilidad, la escalabilidad y la distribución de los componentes.

2. Stateless: cada solicitud hecha al servidor debe contener toda la información necesaria para la correcta ejecución de la solicitud. Esto implica que el servidor no debe almacenar ninguna información sobre el contexto del cliente para utilizarla en futuras solicitudes (por ejemplo, almacenar los datos de la sesión del usuario). Así, promovemos la fiabilidad y la escalabilidad.

3. Cache: a fin de aumentar la reutilización de los datos y mejorar el rendimiento del sistema evitando un procesamiento innecesario, es esencial que las respuestas a las solicitudes puedan ser «cacheadas». Un inconveniente de esta restricción es la posible reducción de la fiabilidad. Por lo tanto, el servidor debe ser capaz de aplicar mecanismos eficaces para comprender si un determinado recurso puede ser almacenado en caché y cuándo, con el fin de no proporcionar información desactualizada.

4. Interfaces uniformes: una de las características que diferencia al REST de otros estilos es el énfasis que se da a la uniformidad de las interfaces entre los componentes. Esta restricción se subdivide en 4 constraints:

– Los recursos deben ser identificables. Un concepto elemental del REST son los recursos, los cuales pueden ser un objeto, información o cualquier concepto abstracto que pueda ser nombrado. El caso más común es el uso de URIs para identificar y localizar los recursos en un servidor.

– Los recursos deben ser manipulados a través de representaciones. Una representación es una secuencia de bytes que determina el estado actual o previsto de un recurso. Puede ser en forma de documentos HTML, XML, JSON, CSV, JPEG, etc.

– Los mensajes deben ser auto descriptivos, es decir, cualquier componente intermedio, (por ejemplo, un proxy), puede interceptar y comprender la semántica del mensaje intercambiado. En el contexto del HTTP, podemos ejemplificar el uso correcto de los métodos, de los status codes y de los metadatos (por ejemplo, los parámetros del header). Es importante destacar que los métodos de solicitud (GET, POST, PATCH, etc.) no forman parte del estilo arquitectónico, sino del protocolo HTTP.

– La hipermedia debería ser el motor del estado de la aplicación. Mejor conocida como HATEOAS (Hypermedia As The Engine Of Application State), esta restricción apoya no sólo el descubrimiento y la manipulación de nuevos recursos para reducir el acoplamiento, sino que también promueve la auto documentación. La idea general es que el cliente, en posesión de un recurso, pueda determinar sus acciones subsiguientes de acuerdo con el control de hipermedia apropiado (por ejemplo, a través de enlaces). La siguiente imagen ilustra un ejemplo (en rojo) de la aplicación del HATEOAS.

5. Sistema en capas: el objetivo de esta constraint es lograr altos requerimientos de escalabilidad, permitiendo que los clientes no se comuniquen directamente con los servidores, sino con los intermediarios. Ejemplos de esto son los Load Balancers, Proxies y Cache Servers. El inconveniente de esta restrición es el posible aumento de la latencia de la red, en la que se necesitan más comunicaciones a medida que se agregan nuevas capas.

6. Código a petición: permite ampliar la funcionalidad del cliente mediante el suministro y la ejecución de códigos a petición, en forma de applets o scripts, por ejemplo. Sin embargo, debido a que no todos los servicios o consumidores pueden ejecutar un código a pedido, ya sea por restricciones comerciales o restricciones de seguridad, esta constraint es considerada opcional, dando más poder y flexibilidad al estilo.

Como se puede ver, hay mucho más en el REST que sólo el uso de representaciones JSON o los métodos HTTP. Por cierto, el JSON ni siquiera se menciona en la tesis de Fielding. Se utilizaron documentos HTML e imágenes JPEG para ejemplificar las representaciones de los recursos. El HTTP no es una restricción de estilo, dejándonos libres para utilizar cualquier otro protocolo de transferencia.

Con esta variedad de interpretaciones sobre el REST, vale la pena mencionar el nombre de Leonard Richardson, quien propuso un modelo de madurez para facilitar la implementación de los servicios HTTP hacia la «gloria» del REST.

El nivel más bajo consiste básicamente en utilizar el protocolo HTTP, para el transporte de información en POX (Plain Old XML). El nivel 1 tiene como objetivo romper el servicio en endpoints más pequeños que ofrecen diferentes recursos. El nivel 2 introduce un conjunto de operaciones que nos permiten manipular los recursos a través de métodos (verbos) ya existentes en el HTTP. Por último, el último nivel de madurez requiere la aplicación del HATEOAS.

También existe un modelo más completo (Classification of HTTP-based APIs) que considera los servicios SOAP – los cuales también se implementan sobre el HTTP, a pesar de que en su mayoría utilizan el método POST en las solicitudes y el XML como representación. En este punto radica una de las principales diferencias entre REST y SOAP: mientras que el primero es un estilo arquitectónico, el segundo es un protocolo que define con precisión cómo deben representarse los mensajes/recursos. Las ventajas y desventajas de cada enfoque quedan para el siguiente post.

En resumen, este artículo pretende mostrar cómo el estilo arquitectónico REST impone ciertas restricciones que hacen que los servicios sean genuinamente RESTful. Sin embargo, es común que algunos desarrolladores no respeten un subconjunto de estas restricciones. En esos casos, lo más coherente sería, quizás, denominar a tales implementaciones como REST-based Services (servicios basados en REST), en lugar de RESTful.

Como perspectivas futuras, es posible notar una continuidad y evolución en la adopción del REST, similares a iniciativas como el Open Banking, Government Digital Service, Open API, Open Data Protocol, entre otras. Además, se han difundido algunas tecnologías, como GraphQL, para mejorar algunas deficiencias existentes en el REST. Además de eso, las APIs semánticas que utilizan ontologías para proporcionar datos conectados -ya publicadas por algunas entidades gubernamentales del Reino Unido, por ejemplo – han fomentado el uso de consultas mediante SPARQL y la ejecución de análisis de datos más sofisticados, automatizando los procesos de descubrimiento y composición de servicios basados en REST.»

Bruno Oliveira

Prime Solutions – Ingeniero de Software