Transferencia de estado representacional (REST)

La transferencia de estado representacional o REST por sus siglas en inglés Representational state transfer ​​es un estilo de arquitectura de software que se creó para guiar el diseño y desarrollo de la arquitectura para la World Wide Web. REST define un conjunto de restricciones sobre cómo debe comportarse la arquitectura de un sistema hipermedia distribuido a escala de Internet, como la Web. El estilo arquitectónico REST enfatiza la escalabilidad de las interacciones entre los componentes, las interfaces uniformes, la implementación independiente de los componentes y la creación de una arquitectura en capas para facilitar el almacenamiento en caché de los componentes para reducir la latencia percibida por el usuario, reforzar la seguridad y encapsular los sistemas heredados.

REST se ha empleado en toda la industria del software y es un conjunto de pautas ampliamente aceptado para crear API web confiables y sin estado. Una API web que obedece las restricciones REST se describe informalmente como RESTful. Las API web RESTful generalmente se basan libremente en métodos HTTP para acceder a los recursos a través de parámetros codificados en URL y el uso de JSON o XML para transmitir datos.

Los "recursos web" se definieron por primera vez en la World Wide Web como documentos o archivos identificados por sus URL. Hoy en día, la definición es mucho más genérica y abstracta e incluye toda cosa, entidad o acción que pueda ser identificada, nombrada, direccionada, manipulada o realizada de cualquier forma en la Web. En un servicio web RESTful, las solicitudes realizadas al URI de un recurso obtienen una respuesta con una carga útil formateada en HTML, XML, JSON o algún otro formato. Por ejemplo, la respuesta puede confirmar que el estado del recurso ha cambiado. La respuesta también puede incluir enlaces de hipertexto a recursos relacionados. El protocolo más común para estas solicitudes y respuestas es HTTP. Proporciona operaciones (métodos HTTP) como GET, POST, PUT y DELETE.Mediante el uso de un protocolo sin estado y operaciones estándar, los sistemas RESTful buscan un rendimiento rápido, confiabilidad y la capacidad de crecer mediante la reutilización de componentes que se pueden administrar y actualizar sin afectar el sistema en su totalidad, incluso mientras se está ejecutando.

El objetivo de REST es aumentar el rendimiento, la escalabilidad, la simplicidad, la modificabilidad, la visibilidad, la portabilidad y la confiabilidad. Esto se logra siguiendo los principios REST, como una arquitectura cliente-servidor, ausencia de estado, almacenamiento en caché, uso de un sistema en capas, soporte para código bajo demanda y uso de una interfaz uniforme. Estos principios deben seguirse para que el sistema sea clasificado como RESTful.

Etimología

El término transferencia de estado representacional fue introducido y definido en 2000 por Roy Fielding en su tesis doctoral. El término pretende evocar una imagen de cómo se comporta una aplicación web bien diseñada: es una red de recursos web (una máquina de estado virtual) donde el usuario avanza a través de la aplicación seleccionando enlaces (por ejemplo, http://www.example.com/articles/21), lo que da como resultado que la siguiente representación del recurso (el siguiente estado de la aplicación) se transfiera al cliente y se represente para el usuario.

Historia

La Web comenzó a entrar en el uso cotidiano en 1993-1994, cuando comenzaron a estar disponibles los sitios web para uso general. En ese momento, solo había una descripción fragmentada de la arquitectura de la Web, y había presión en la industria para acordar algún estándar para los protocolos de interfaz Web. Por ejemplo, se agregaron varias extensiones experimentales al protocolo de comunicación (HTTP) para admitir servidores proxy y se propusieron más extensiones, pero se necesitaba una arquitectura web formal con la que evaluar el impacto de estos cambios.

Los grupos de trabajo del W3C y el IETF comenzaron a trabajar juntos en la creación de descripciones formales de los tres estándares principales de la Web: URI, HTTP y HTML. Roy Fielding estuvo involucrado en la creación de estos estándares (específicamente HTTP 1.0 y 1.1 y URI), y durante los siguientes seis años desarrolló el estilo arquitectónico REST, probando sus restricciones en los estándares de protocolo de la Web y usándolo como un medio para definir mejoras arquitectónicas y para identificar desajustes arquitectónicos. Fielding definió REST en su tesis doctoral de 2000 "Estilos arquitectónicos y diseño de arquitecturas de software basadas en red" en UC Irvine.

Para crear el estilo arquitectónico REST, Fielding identificó los requisitos que se aplican al crear una aplicación basada en una red mundial, como la necesidad de una barrera de entrada baja para permitir la adopción global. También analizó muchos estilos arquitectónicos existentes para aplicaciones basadas en red, identificando qué funciones se comparten con otros estilos, como el almacenamiento en caché y las funciones cliente-servidor, y aquellas que son exclusivas de REST, como el concepto de recursos. Fielding intentaba categorizar la arquitectura existente de la implementación actual e identificar qué aspectos deberían considerarse centrales para los requisitos de comportamiento y rendimiento de la Web.

Por su naturaleza, los estilos arquitectónicos son independientes de cualquier implementación específica, y aunque REST se creó como parte del desarrollo de los estándares web, la implementación de la web no obedece a todas las restricciones del estilo arquitectónico REST. Los desajustes pueden ocurrir debido a la ignorancia o al descuido, pero la existencia del estilo arquitectónico REST significa que pueden identificarse antes de que se estandaricen. Por ejemplo, Fielding identificó la incrustación de información de sesión en URI como una violación de las restricciones de REST que puede afectar negativamente el almacenamiento en caché compartido y la escalabilidad del servidor. Las cookies HTTP también violaron las restricciones REST porque pueden desincronizarse con el estado de la aplicación del navegador, haciéndolas poco confiables; también contienen datos opacos que pueden ser una preocupación para la privacidad y la seguridad.

Conceptos arquitectónicos

El estilo arquitectónico REST está diseñado para aplicaciones basadas en red, específicamente aplicaciones cliente-servidor. Pero más que eso, está diseñado para el uso a escala de Internet, por lo que el acoplamiento entre el agente de usuario (cliente) y el servidor de origen debe ser lo más liviano (suelto) posible para facilitar la adopción a gran escala. Esto se logra creando una capa de abstracción en el servidor mediante la definición de recursos que encapsulan entidades(por ejemplo, archivos) en el servidor y, por lo tanto, ocultar los detalles de implementación subyacentes (servidor de archivos, base de datos, etc.). Pero la definición es incluso más general que eso: cualquier información que se pueda nombrar puede ser un recurso: una imagen, una consulta de base de datos, un servicio temporal (p. ej., “clima de hoy en Londres”) o incluso una colección de otros recursos. Este enfoque permite la mayor interoperabilidad entre clientes y servidores en un entorno a escala de Internet de larga duración que cruza los límites organizacionales (de confianza).

Los clientes solo pueden acceder a los recursos mediante URI. En otras palabras, el cliente solicita un recurso utilizando un URI y el servidor responde con una representación del recurso. Una representación de un recurso es otro concepto importante en REST; para garantizar que las respuestas puedan ser interpretadas por el mayor número posible de aplicaciones cliente, se envía una representación del recurso en formato de hipertexto. Así, un recurso es manipulado a través de representaciones de hipertexto transferidas en mensajes entre los clientes y servidores.

El fuerte desacoplamiento del cliente y el servidor junto con la transferencia de información basada en texto utilizando un protocolo de direccionamiento uniforme proporcionó la base para cumplir con los requisitos de la Web: solidez (escalabilidad anárquica), implementación independiente de componentes, transferencia de datos de grano grande y una barrera de entrada baja para lectores de contenido, autores de contenido y desarrolladores por igual.

Propiedades arquitectónicas

Las restricciones del estilo arquitectónico REST afectan a las siguientes propiedades arquitectónicas:

• rendimiento en las interacciones de los componentes, que puede ser el factor dominante en el rendimiento percibido por el usuario y la eficiencia de la red;
• escalabilidad que permite soportar un gran número de componentes e interacciones entre componentes;
• simplicidad de una interfaz uniforme;
• modificabilidad de los componentes para satisfacer las necesidades cambiantes (incluso mientras se ejecuta la aplicación);
• visibilidad de la comunicación entre los componentes por parte de los agentes de servicio;
• portabilidad de los componentes moviendo el código del programa con los datos;
• confiabilidad en la resistencia a la falla a nivel del sistema en presencia de fallas dentro de los componentes, conectores o datos.

Restricciones arquitectónicas

El estilo arquitectónico REST define seis restricciones de guía. Cuando estas restricciones se aplican a la arquitectura del sistema, obtiene propiedades no funcionales deseables, como rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad, portabilidad y confiabilidad. Un sistema que cumple con algunas o todas estas restricciones se denomina vagamente RESTful.

Las restricciones REST formales son las siguientes:

Arquitectura cliente-servidor

El patrón de diseño cliente-servidor hace cumplir el principio de separación de preocupaciones: separar las preocupaciones de la interfaz de usuario de las preocupaciones de almacenamiento de datos. De este modo se mejora la portabilidad de la interfaz de usuario. En el caso de la Web, se ha desarrollado una plétora de navegadores web para la mayoría de las plataformas sin necesidad de conocer ninguna implementación de servidor. La separación también simplifica los componentes del servidor, mejorando la escalabilidad, pero lo que es más importante, permite que los componentes evolucionen de forma independiente (escalabilidad anárquica), lo cual es necesario en un entorno a escala de Internet que involucra múltiples dominios organizacionales.

Apatridia

En informática, un protocolo sin estado es un protocolo de comunicaciones en el que el receptor, generalmente un servidor, no retiene información de la sesión. El cliente envía los datos relevantes de la sesión al receptor de tal manera que cada paquete de información transferido se puede entender de forma aislada, sin información de contexto de los paquetes anteriores en la sesión. Esta propiedad de los protocolos sin estado los hace ideales en aplicaciones de alto volumen, ya que aumenta el rendimiento al eliminar la carga del servidor causada por la retención de la información de la sesión.

Capacidad de almacenamiento en caché

Al igual que en la World Wide Web, los clientes e intermediarios pueden almacenar en caché las respuestas. Las respuestas deben, implícita o explícitamente, definirse a sí mismas como almacenables en caché o no almacenables en caché para evitar que los clientes proporcionen datos obsoletos o inapropiados en respuesta a solicitudes posteriores. El almacenamiento en caché bien administrado elimina parcial o completamente algunas interacciones cliente-servidor, lo que mejora aún más la escalabilidad y el rendimiento.

Sistema en capas

Normalmente, un cliente no puede saber si está conectado directamente al servidor final oa un intermediario en el camino. Si se coloca un proxy o un balanceador de carga entre el cliente y el servidor, no afectará sus comunicaciones y no será necesario actualizar el código del cliente o del servidor. Los servidores intermediarios pueden mejorar la escalabilidad del sistema al permitir el equilibrio de carga y al proporcionar cachés compartidos. Además, la seguridad se puede agregar como una capa sobre los servicios web, separando la lógica comercial de la lógica de seguridad. Agregar seguridad como una capa separada hace cumplir las políticas de seguridad. Finalmente, los servidores intermediarios pueden llamar a muchos otros servidores para generar una respuesta al cliente.

Código bajo demanda (opcional)

Los servidores pueden ampliar o personalizar temporalmente la funcionalidad de un cliente mediante la transferencia de código ejecutable: por ejemplo, componentes compilados como applets de Java o scripts del lado del cliente como JavaScript.

Interfaz uniforme

La restricción de interfaz uniforme es fundamental para el diseño de cualquier sistema RESTful. Simplifica y desacopla la arquitectura, lo que permite que cada parte evolucione de forma independiente. Las cuatro restricciones para esta interfaz uniforme son:

• Identificación de recursos en solicitudes: los recursos individuales se identifican en solicitudes, por ejemplo, utilizando URI en servicios web RESTful. Los recursos en sí mismos están conceptualmente separados de las representaciones que se devuelven al cliente. Por ejemplo, el servidor podría enviar datos desde su base de datos como HTML, XML o JSON, ninguno de los cuales es una representación interna del servidor.
• Manipulación de recursos a través de representaciones: cuando un cliente tiene una representación de un recurso, incluidos los metadatos adjuntos, tiene suficiente información para modificar o eliminar el estado del recurso.
• Mensajes autodescriptivos: cada mensaje incluye suficiente información para describir cómo procesar el mensaje. Por ejemplo, el tipo de medio puede especificar qué analizador invocar.
• Hipermedia como motor del estado de la aplicación (HATEOAS): después de haber accedido a un URI inicial para la aplicación REST, similar a un usuario web humano que accede a la página de inicio de un sitio web, un cliente REST debería poder usar enlaces proporcionados por el servidor dinámicamente para descubrir todos los recursos disponibles que necesita. A medida que avanza el acceso, el servidor responde con un texto que incluye hipervínculos a otros recursos que están disponibles actualmente. No es necesario que el cliente esté codificado con información sobre la estructura o la dinámica de la aplicación.

Modelos de clasificación

Se han desarrollado varios modelos para ayudar a clasificar las API de REST según su adherencia a varios principios de diseño de REST, como el modelo de madurez de Richardson.

Aplicado a servicios web

Las API de servicios web que se adhieren a las restricciones arquitectónicas REST se denominan API RESTful. Las API RESTful basadas en HTTP se definen con los siguientes aspectos:

• un URI base, como http://api.example.com/;
• métodos HTTP estándar (p. ej., GET, POST, PUT y DELETE);
• un tipo de medio que define elementos de datos de transición de estado (p. ej., Atom, microformatos, application/vnd.collection+json, etc.). La representación actual le dice al cliente cómo redactar solicitudes de transiciones a todos los siguientes estados de aplicación disponibles. Esto podría ser tan simple como un URI o tan complejo como un applet de Java.

Semántica de métodos HTTP

La siguiente tabla muestra cómo se pretende utilizar los métodos HTTP en las API HTTP, incluidas las RESTful.

método HTTP	Descripción
GET	Obtenga una representación del estado del recurso de destino.
POST	Deje que el recurso de destino procese la representación incluida en la solicitud.
PUT	Cree o reemplace el estado del recurso de destino con el estado definido por la representación incluida en la solicitud.
DELETE	Elimina el estado del recurso de destino.

El método GET es seguro, lo que significa que aplicarlo a un recurso no genera un cambio de estado del recurso (semántica de solo lectura). Los métodos GET, PUT y DELETE son idempotentes, lo que significa que aplicarlos varias veces a un recurso da como resultado el mismo cambio de estado del recurso que aplicarlos una vez, aunque la respuesta puede diferir. Los métodos GET y POST se pueden almacenar en caché, lo que significa que las respuestas a ellos se pueden almacenar para su futura reutilización.

Discusión

A diferencia de los servicios web basados ​​en SOAP, no existe un estándar "oficial" para las API web RESTful. Esto se debe a que REST es un estilo arquitectónico, mientras que SOAP es un protocolo. REST no es un estándar en sí mismo, pero las implementaciones RESTful hacen uso de estándares, como HTTP, URI, JSON y XML. Muchos desarrolladores describen sus API como RESTful, aunque estas API no cumplen con todas las restricciones arquitectónicas descritas anteriormente (especialmente la restricción de interfaz uniforme).