REST

Un breve tutorial sobre el concepto arquitectónico del REpresentational State Transfer (REST).

¿Qué es REST?

Representational State Transfer (REST), cuyas mejores traducciones pueden ser «Transferencia de Estado Representativo» o «Transferencia Figurativa de Estado»,  es un estilo de arquitectura de software que define a un conjunto de restricciones a las cuales debe atenerse al momento de crear servicios web1. De esta forma se garantiza que los servicios creados brinden un determinado nivel de interoperabilidad.

Los servicios web que cumplen con REST permiten que los sistemas solicitantes accedan y manipulen las representaciones textuales de los recursos web mediante el uso de un conjunto uniforme y predefinido de operaciones sin estado. Otros tipos de servicios web, como los servicios web SOAP, exponen sus propios conjuntos arbitrarios de operaciones.

Acerca del concepto de «estado»

Antes de continuar, resulta importante dejar claro lo que debe entenderse por «estado». En la Ciencia de la Computación, a la que específicamente pertenece la Teoría de Autómatas, un estado es una configuración única que proporciona información de la situación que un autómata guarda tras el «procesamiento» de ciertas cantidad de entradas. Conforme la complejidad de este autómata aumenta (un autómata con pila o una máquina de Turing), el estado puede llegar a ser un conjunto particular de instrucciones las cuales serán ejecutadas en respuesta a la entrada de la máquina. El comportamiento del sistema es una función de (a) la definición del autómata, (b) la entrada y (c) el estado actual2,3,4.

Por otra parte, en términos de procesamiento de datos, un estado es el conjunto completo de propiedades transmitidos por un objeto a un observador por medio de uno o más canales de comunicación2. Cualquier cambio en la naturaleza o cantidad de tales propiedades que sea detectado por el observador constituye la transmisión de información y así un cambio de estado del objeto en cuestión.

Así, todo sistema, mecanismo o protocolo cuyo funcionamiento o comportamiento es distinguible por los cambios en sus configuraciones o propiedades que transmite se dice que está «basado en estados» y que se trata de un sistema «con estado». Uno que no lo es, se le denominará «sin estado» (stateless). Por ejemplo, hay firewalls y servidores sin estado, y HTTP se considera un protocolo sin estado. Una Codificación de caracteres como por ejemplo ISO 2022 se dice que es con estado si la interpretación del valor del código particular depende de los valores de código que lo precedieron.

Restricciones

El estilo arquitectónico REST está descrito por seis restricciones. Estas restricciones fueron originalmente establecidas por Roy Fielding en su disertación doctoral5 y definen la base de lo que hoy se llama estilo RESTful. Las seis restricciones son:

Interfaz uniforme

La restricción de interfaz uniforme define la interfaz entre clientes y servidores. Simplifica y desacopla la arquitectura, lo que permite que cada parte evolucione de forma independiente. Los cuatro principios rectores de la interfaz uniforme son:

Basado en recursos
Los recursos individuales se identifican en las solicitudes que usan una URI como identificadores de recursos. Los recursos mismos están conceptualmente separados de las representaciones que se devuelven al cliente. Por ejemplo, el servidor no envía su base de datos, sino algo de HTML, XML o JSON que representa algunos registros de la base de datos expresados, por ejemplo, en finlandés y codificados en UTF-8, dependiendo de los detalles de la solicitud y la implementación del servidor.
Manipulación de recursos a través de representaciones
Cuando un cliente tiene la representación de un recurso, incluidos los metadatos, tiene suficiente información para modificar o eliminar el recurso en el servidor, siempre que tenga permiso para hacerlo.
Mensajes autodescriptivos
Cada mensaje incluye suficiente información para describir cómo procesar el mensaje. Por ejemplo, qué analizador invocar puede especificarse mediante un tipo de medio de Internet (anteriormente conocido como tipo MIME). Las respuestas también indican explícitamente su capacidad de caché.
Hipermedios como motor del estado de la aplicación
Representado en inglés como HATEOAS (Hypermedia as the Engine of the Application State), describe como los clientes proporcionan su estado a través del contenido del cuerpo del mensaje, los parámetros de la cadena de consulta, los encabezados de la solicitud y el URI solicitado (el nombre del recurso). Los servicios entregan el estado a los clientes a través del contenido del cuerpo, los códigos de respuesta y los encabezados de respuesta. Esto se conoce técnicamente como hipermedios (o hipervínculos dentro del hipertexto).

 

Además de la descripción anterior, HATEOAS también significa que, cuando sea necesario, los enlaces están contenidos en el cuerpo devuelto (o en los encabezados) para suministrar el URI para recuperar el objeto mismo o los objetos relacionados.

La interfaz uniforme que deben proporcionar todos los servicios REST es fundamental para su diseño.

Sin estado

Como REST indica, la carencia de estado es clave. Básicamente, lo que esto significa es que el estado necesario para manejar la solicitud hecha,  se encuentra dentro de la solicitud misma, ya sea como parte del URI, los parámetros de la cadena de consulta, el cuerpo o los encabezados. El URI identifica de manera única el recurso y el cuerpo contiene el estado (o cambio de estado) de ese recurso. Luego, una vez que el servidor procesa la solicitud, el estado apropiado o sus elementos, se comunican al cliente a través de encabezados, estado y cuerpo de respuesta.

Quienes hemos estado en la industria del desarrollo de software por un tiempo estaremos acostumbrados a programar dentro de un contenedor que nos proporciona el concepto de «sesión» y que mantiene el «estado» en múltiples solicitudes HTTP. En REST, el cliente debe incluir toda la información para que el servidor cumpla con la solicitud, reenviando el estado según sea necesario si ese estado debe abarcar varias solicitudes. La carencia de estado permite una mayor escalabilidad ya que el servidor no tiene que mantener, actualizar o comunicar ese estado de sesión. Además, los balanceadores de carga no tienen que preocuparse por la afinidad de la sesión para los sistemas sin estado.

Entonces, ¿cuál es la diferencia entre el estado y un recurso? Estado, o estado de aplicación, es aquel por el que el servidor se preocupa para cumplir con una solicitud —los datos necesarios para la sesión o solicitud actual. Un recurso, o estado de recursos, son los datos que definen la representación de recursos — los datos almacenados en la base de datos, por ejemplo. El «estado de la aplicación» son los datos que pueden variar según el cliente y solicitud. El «estado del recurso», por otro lado, es constante para cada cliente que lo solicita.

¿Alguna vez tuvo problemas con el botón de retroceso con una aplicación web en cierto momento porque esperaba que hiciera las cosas en cierto orden? Eso es porque se violó el principio de «sin estado». Hay casos en que no se honra este principio, como el OAuth de «tres patas», en la limitación de la tasa de llamadas API, etcétera. Sin embargo, es mejor hacer los mayores esfuerzos posibles para garantizar que el «estado de la aplicación» no abarque múltiples solicitudes del o los servicios.

«Cacheable»

Al igual que los servidores de la World Wide Web, los clientes pueden almacenar respuestas en caché. Las respuestas deben, por lo tanto, implícita o explícitamente, definirse a sí mismas como «cacheables», o no, para evitar que los clientes reutilicen datos obsoletos o inapropiados en respuesta a solicitudes adicionales. El almacenamiento en caché bien gestionado elimina parcial o completamente algunas interacciones cliente-servidor, mejorando aún más la escalabilidad y el rendimiento.

Cliente-Servidor

La interfaz uniforme separa a clientes de servidores. Esta separación de asuntos significa que, por ejemplo, a los clientes no les preocupa el almacenamiento de datos (que permanece interno a cada servidor), de modo que se mejora la portabilidad del código del cliente. Los servidores no se preocupan por la interfaz de usuario o el estado del usuario, por lo que los servidores pueden ser más simples y escalables. Los servidores y clientes también pueden ser reemplazados y desarrollados independientemente, siempre y cuando la interfaz no se modifique.

Sistema de capas

Un cliente normalmente no puede decir si está conectado directamente al servidor final, o a un intermediario en el camino. Los servidores intermediarios pueden mejorar la escalabilidad del sistema al habilitar el equilibrio de carga y al proporcionar cachés compartidos. Las capas también pueden aplicar políticas de seguridad.

Código bajo demanda (opcional)

Los servidores pueden ampliar o personalizar temporalmente la funcionalidad de un cliente transfiriéndole lógica que puede ejecutar. Ejemplos de esto pueden incluir componentes compilados, como los applets de Java, y los scripts del lado del cliente, como JavaScript.

Cumplimiento

Cumplir con estas restricciones es ajustarse al estilo arquitectónico REST. Adoptarlo permitirá que cualquier tipo de sistema de hipermedios distribuido tenga propiedades emergentes deseables, tales como rendimiento, escalabilidad, simplicidad, modificabilidad, visibilidad, portabilidad y confiabilidad. La única restricción opcional de la arquitectura REST es el código bajo demanda. Si un servicio viola cualquier otra restricción, no puede referirse estrictamente como RESTful.

Diseño

El diagrama de abajo muestra gráficamente lo que el diseño de una REST API debe considerar y las interrelaciones entres estas consideraciones. Para más detalle sobre esto, consultar el artículo de Love Sharma6.

Source: «Principles & Best practices of REST API Design«

Referencias

  1. «Representational state transfer«, Wikipedia, web. Visited: 2018.07.08. URL: https://en.wikipedia.org/wiki/Representational_state_transfer.
  2. «Estado (informática)«, Wikipedia, web. Visited: 2018.07.08. URL: https://es.wikipedia.org/wiki/Estado_(informática).
  3. «State (computer science)«, Wikipedia, web. Visited: 2018.07.08. URL: https://en.wikipedia.org/wiki/State_(computer_science).
  4.  John E. Hopcroft, Rajeev Motwani & Jeffrey D. Ullman, «Introduction to Automata Theory, Languages, and Computation», Addyson-Wesley, 3rd Edition, 2007, USA. URL: http://infolab.stanford.edu/~ullman/ialc.html.
  5. Roy Thomas Fielding, «Architectural Styles and the Design of Network-based Software Architectures«,  University Of California, Irvine, Ph. D. dissertation, 2000. USA. URL: https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
  6. Love Sharma, «Principles & Best practices of REST API Design«, medium.com, web. Published: 2021.11.21; visited: 2021.12.07. URL: https://zonito.medium.com/best-practice-and-cheat-sheet-for-rest-api-design-6a6e12dfa89f.

Twitter Wordpress eMail
© Todos los derechos reservados.
Dr. Eduardo René Rodríguez Avila 		Creación: 2018.07.08
Última actualización: 2021.12.07
El contenido de este sitio puede ser copiado y reproducido libremente mientras no sea alterado y se cite su origen. Marcas y productos registrados son citados por referencia y sin fines de lucro o dolo. Todas las opiniones son a título personal del o los autores de éstas y, salvo sea expresado de otro modo, deben considerarse como registro y expresión de la experiencia de uso de aquello que es tratado. Para conocer más sobre la posición de privacidad y responsabilidad de lo que se presenta en este sitio web y como ha sido obtenido, consulte la declaración al respecto.