Características de los servicios REST

REST no es un estándar, simplemente define unos principios de arquitectura a seguir para implementar aplicaciones o servicios en red. Sin embargo, REST se basa en estándares para su implementación: HTTP, XML, etc. Los servicios REST tienen las siguientes características:

Cliente-Servidor
Los servicios REST deben estar basados en una arquitectura Cliente-Servidor. Un servidor que contiene los recursos y estados de los mismos, y unos clientes que acceden a ellos.

Sin estado
Los Servicios REST pueden ser escalados hasta alcanzar grandes rendimientos para abarcar la demanda de todos los posibles clientes. Esto implica que sea necesario crear granjas de servidores con balanceo de cargas y failover o diferentes niveles de servidores para minimizar el tiempo de respuesta a los clientes. Al utilizar servidores intermedios, es necesario que los clientes REST envíen la información completa e independiente en cada solicitud de estado de un recurso. De esta manera, los servidores intermedios pueden reenviar, enrutar, balancear sin necesidad de que los servidores intercambien información de sesiones de clientes.
Una solicitud completa e independiente no requiere que el servidor, mientras procesa la solicitud, tenga que almacenar ningún tipo de contexto o sesión. Un cliente REST debe incluir dentro de la cabecera y cuerpo HTTP todos los parámetros, contexto y datos necesarios para que el servidor genere la respuesta. Esto aumenta el rendimiento del servicio REST y simplifica el diseño e implementación del servidor ya que la ausencia de sesiones de clientes elimina la necesidad de sincronizar datos de sesión con aplicaciones externas.

Información cacheable
Para mejorar la eficiencia en el tráfico de red, las respuestas del servidor deben tener la posibilidad de ser marcadas como cacheables. Esta información es utilizada por los clientes REST para decidir si hacer una copia local del recurso con la fecha y hora del último cambio de estado del recurso. En tal caso, el cliente realiza solicitudes del estado del recurso de forma que, si el estado no ha cambiado, el servidor solo le responde con un mensaje muy pequeño indicando que no ha cambiado. Esto permite optimizar el tráfico de red.

Interfaz uniforme
Una de las características principales de los servicios Web REST es el uso explícito de métodos HTTP (HyperText Transfer Protocol). Estos métodos son indicados en la cabecera HTTP por parte del cliente y son los siguientes:
• GET: recoge información de un recurso
• PUT: modifica o actualiza el estado de un recurso
• POST: crea un nuevo recurso en el servidor
• DELETE: elimina un recurso del servidor.
Habitualmente una URL en una solicitud HTTP GET identifica un recurso. Por ejemplo, en la siguiente solicitud se estaría solicitando el estado de un recurso llamado “SensorHumedad_001” dentro del catálogo de sensores de MiEmpresa:
http://www.MiEmpresa.com/Sensores/SensorHumedad_001

Otra manera de solicitar información a un servidor es construyendo una URL que incluya parámetros que definan los criterios de búsqueda en el servidor para que pueda encontrar los recursos solicitados:
http://www.MiEmpresa.com/Sensores?Tipo=humedad&id=001

Un recurso es una URL lógica, no física. De este modo no es necesario que en el servidor exista una página HTML para cada uno de los sensores. Con un método POST se generaría el nuevo recurso en el servidor, el cual sería accesible como URL lógica.

El modo en el que el servidor maneja las solicitudes de los clientes debe estar oculto para los éstos. Un cliente no debe saber el lenguaje de programación utilizado en el servidor ni cómo éste está generando la información; simplemente debe saber el modo de acceder a la información. Esto permite migrar de un servidor a otro, de un lenguaje a otro sin necesidad de hacer cambios en los clientes existentes.

En los principio definidos por REST se diferencia el método GET de los demás ya que éste no debe tener efectos de cambio en la información contenida en el servidor. Los métodos PUT, POST y DELETE modifican un recurso, pero el GET solo debe recoger información, nunca modificar el recurso.

Acceso a recursos por nombre
Un sistema REST está compuesto por recursos que son accedidos mediante URL, y éstas deben ser intuitivas, predecibles y fáciles de entender y componer. Una manera de conseguirlo es mediante una estructura jerárquica, similar a directorios. Puede existir un nodo raíz único, a partir del cual se crean los subdirectorios que expongan las áreas principales de los servicios, hasta formar un árbol con la información de los recursos.
El acceso a los recursos se realiza como composición de una URL que identifique el recurso, y debe ser la misma aunque la implementación en el servidor se modifique. La URL compuesta no debe contener llamadas a funciones que ejecuten código en el servidor, por lo que no deberían ser direcciones de archivos que ejecuten acciones (páginas con extensión .jsp, .php, .asp).

Recursos relacionados
Los recursos accesibles en el servidor suelen estar relacionados unos con otros. Por tanto, la información de estado de un recurso debería permitir acceder a otros recursos. Esto se consigue añadiendo en el estado de los recursos links o URL de otros recursos. Por ejemplo, se podría pedir un recurso cuyo estado identifique los sensores de un determinado tipo:
http://www.MiEmpresa.com/Sensores?Tipo=humedad
El servidor podría devolver el listado de todos los sensores de ese tipo, y dentro de la información del estado se puede incluir un link a cada uno de los sensores, añadiendo una capacidad de Drill-down para acceder al máximo detalle. La respuesta del servidor a la solicitud anterior podría ser similar a esta:
{Id}SensorHumedad_001 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_001
{Id}SensorHumedad_002 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_002
{Id}SensorHumedad_003 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_003
{Id}SensorHumedad_004 {Detalle}http://www.MiEmpresa.com/Sensores/SensorHumedad_004

Una buena práctica en los servicios REST es no mostrar toda la información del estado de un recurso en una solicitud, sino mostrar la información de manera gradual. Esto permite minimizar el uso de la red si el cliente no necesita muchos detalles de un determinado recurso. Esto se puede conseguir incluyendo links en el estado del recurso, siendo estos links otros recursos con mayor nivel de detalle.

Respuesta en un formato conocido
La representación de un recurso refleja el estado actual del mismo y sus atributos en el instante en el que el cliente ha realizado la solicitud. Este resultado puede representar simplemente el valor de una variable en un instante de tiempo, un registro de una Base de Datos o cualquier otro tipo de información. En cualquiera de los casos, la información debe ser entregada al cliente en un formato comprensible para ambas partes y contenida dentro del cuerpo HTTP. Este contenido debe ser simple y compresible por un humano y, por supuesto, interpretable por una aplicación. Esto permite utilizar el servicio REST por diferentes clientes independientemente del lenguaje con el que se hayan programado.

Los formatos más habituales son JSON (JavaScript Object Notation) y XML (Extensible Markup Language), aunque se aceptan otros, como CSV (Comma Separated Values). Cada formato tiene sus ventajas y desventajas. Puesto que JSON fue diseñado para JavaScript, su interpretación es muy directa en este entorno. XML es fácil de expandir y contraer ya que la información está anidada; además, es un formato muy conocido. CSV, por su parte, es un formato compacto.

En los servicios REST, puesto que pueden existir diferentes tipos de clientes, no se aconseja implementar un servidor que devuelva el estado de un recurso en un solo formato. Esto se puede conseguir de diferentes maneras, como por ejemplo, crear en el servidor una URL diferente para cada formato, o escribiendo un parámetro en la misma URL que el servidor interprete. A continuación se muestran ambas opciones:
http://www.MiEmpresa.com/Sensores/xml/Sensor001
http://www.MiEmpresa.com/Sensores/Sensor001?Output=xml