Protocolo REST

El protocolo REST

REST son las siglas de Representation State Transfer. Los servicios web basados en REST intentan emular al protocolo HTTP o protocolos similares mediante la restricción de establecer la interfaz a un conjunto conocido de operaciones estándar (por ejemplo GET, PUT, POST y DELETE). Por tanto, este estilo se centra más en interactuar con recursos con estado que con mensajes y operaciones.

Como ya se mencionó, el término fue introducido en la tesis doctoral de Roy Fielding en el año 2000.

Cabe destacar que REST no es un estándar, pero está basado en estándares como los siguientes:

• HTTP

• URL

• Representación de los recursos: XML/HTML/GIF/JPEG etc.

• Tipos MIME: text/xml, text/html, etc.

REST es una colección de principios de arquitectura y un estilo de arquitectura de software para construir sistemas distribuidos basados en mecanismos que definen y acceden a recursos como internet.

El término REST siempre es empleado para describir un framework de trasmisión de datos sobre un protocolo como HTTP sin agregar capas semánticas adicionales o manejos de sesión.

Objetivos del estilo de arquitectura REST

Escalabilidad de la interacción con los componentes. La web ha crecido exponencialmente sin degradar su rendimiento. Una prueba de ellos es la variedad de clientes que pueden acceder a través de la web: estaciones de trabajo, sistemas industriales, dispositivos móviles, etc.

Generalidad de interfaces. Gracias al protocolo HTTP, cualquier cliente puede interactuar con cualquier servidor HTTP sin ninguna configuración especial. Esto no es del todo cierto para otras alternativas, como SOAP para los servicios web.

Puesta en funcionamiento independiente. Este hecho es una realidad que debe tratarse cuando se trabaja en Internet. Los clientes y servidores pueden ser puestas en funcionamiento durante años. Por tanto, los servidores antiguos deben ser capaces de entenderse con clientes actuales y viceversa. Diseñar un protocolo que permita este tipo de características resulta muy complicado. HTTP permite la extensibilidad mediante el uso de las cabeceras con el uso de las URIs, a través de la habilidad para crear nuevos métodos y tipos de contenido.

Compatibilidad con componentes intermedios. Los más populares intermediarios son varios tipos de proxys para web. Algunos de ellos, las caches, se utilizan para mejorar el rendimiento. Otros permiten reforzar las políticas de seguridad: firewalls. Por último, otro tipo importante de intermediarios, gateway, permiten encapsular sistemas no propiamente web. Por tanto, la compatibilidad con intermediarios nos permite reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.

El principio fundamental de REST es que emplea el Uniform Resource Identifier (URI) para ubicar y acceder a la representación de un recurso. La representación de un recurso (conocida como representational state) puede ser creada, recuperada, modificada y borrada. Se debe recordar que las conversaciones no mantienen estado.  

Como indica Roy Fielding, uno de los principios de REST es que éste explota las tecnologías existentes, estándares y protocolos de la Internet, como por ejemplo HTTP.

Esta confianza en las cosas existentes hace que REST sea fácil de aprender y simple de utilizar respecto a otros estándares de intercambio de mensajes web.

En un sistema REST basado en HTTP, se pueden emplear los métodos HTTP estándares como GET, PUT, POST y DELETE para acceder al estado representacional del recurso:

GET: Se utiliza éste método para transferir el estado representacional actual de un recurso desde el publicador hacia el consumidor.

PUT: Se utiliza éste método para transferir el estado representacional actual de un recurso desde el consumidor hacia el publicador.

POST: Se utiliza este método para transferir un nuevo estado representacional de un recurso desde el consumidor al publicador.

DELETE: Se utiliza éste método para transferir información necesaria para cambiar el estado representacional de un recurso al estado ―eliminado‖ (o borrado).

Se puede hacer una analogía como la siguiente:

Asimismo, REST emplea las siguientes restricciones:

Identificación de recursos y manipulación de ellos a través de representaciones. Esto se consigue mediante el uso de URIs. HTTP es un protocolo centrado en URIs. Los recursos son los objetos lógicos a los que se le envían mensajes. Los recursos no pueden ser directamente accedidos o modificados. Más bien, se trabaja con representaciones de ellos. Cuando se utiliza un método PUT para enviar información, se coge como una representación de lo que nos gustaría que fuera el estado del recurso. Internamente, el estado del recurso puede ser cualquier cosa desde una base de datos relacional a un fichero de texto.  

Mensajes autodescriptivos. REST dicta que los mensajes HTTP deberían ser tan descriptivos como sea posible. Esto hace posible que los intermediarios interpreten los mensajes y ejecuten servicios en nombre del usuario. Uno de los modos que HTTP logra esto es por medio del uso de varios métodos estándares, muchos encabezamientos y un mecanismo de direccionamiento. Por ejemplo, las cachés web saben que por defecto el comando GET es cacheable (ya que es side-effect-free); en cambio, POST no lo es. Además, saben como consultar las cabeceras para controlar la caducidad de la información. HTTP es un protocolo sin estado y, cuando se utiliza adecuadamente, es posible interpretar cada mensaje sin ningún conocimiento de los mensajes precedentes.

 Hipermedia como un mecanismo del estado de la aplicación. El estado actual de una aplicación web debería ser capturada en uno o más documentos de hipertexto, y residir tanto en el cliente como en el servidor. El servidor conoce sobre el estado de sus recursos, aunque no intenta seguirle la pista a las sesiones individuales de los clientes. Esta es la misión del navegador, el sabe como navegar de recurso a recurso y recoger información que él necesita o cambiar el estado que necesita cambiar.

Entidades básicas en REST

REST define las siguientes entidades:

Data elements: Consiste de datos, identificadores (URIs y URLs), y representaciones de datos, como documentos HTML, documentos XML e imágenes.

Components: Incluye servidores web, proxies, user agents (navegadores web) y dispositivos móviles.

Connectors: Conectores de clientes, de servidores, cache de navegadores, etc.

Un diseño basado en REST es adecuado cuando:

§ el servicio web no tiene estado. Se puede comprobar verificando si la interacción puede sobrevivir a un reinicio del servidor.

§ una infraestructura de caching puede mejorar el rendimiento. Si los datos que el servicio web devuelve no son dinámicamente generados y pueden ser cacheados, entonces la infraestructura de caching que los servidores web y los intermediarios proporcionan pueden incrementar el rendimiento.

§ tanto el productor como el consumidor del servicio conocen el contexto y contenido que va a ser comunicado. Ya que REST no posee todavía un modo estándar y formal de describir la interfaz de los servicios web, ambas partes deben estar de acuerdo en el modo de intercambiar de información.

§ el ancho de banda es importante y necesita ser limitado. REST es particularmente útil en dispositivos con escasos recursos como PDAs o teléfonos móviles, donde la sobrecarga de las cabeceras y capas adicionales de los elementos SOAP deben ser restringida.

§ la distribución de servicios web o la agregación con sitios web existentes puede ser fácilmente desarrollada mediante REST. Los desarrolladores pueden utilizar tecnologías como AJAX y toolkits como DWR (Direct Web Remoting) para consumir el servicio en sus aplicaciones web.