REST (Representational State Transfer)

Creado en el 2000 hace referencia a “Representational State Transfer” o transferencia representacional de estados.

Si uno se deja guiar por el nombre pareciera como si no tuviese nada que ver con lo que medio se ha oído por ahí acerca del tema: “que sirve para acceder a servicios sencillamente a través de URLs”, por ejemplo.

Pero estudiándolo bien uno nota que al final si hay cierta congruencia.

En REST participan básicamente dos roles. Un cliente y un servidor. El cliente es el sujeto de los dichosos cambios de estados. Entonces imagine el cliente como su navegador web en un estado específico (una página web). Un cambio de estado obviamente significa la transferencia a otra página web.

Una transferencia representacional en web, no es más que la transferencia lograda sencillamente a través de URLs. Y es precisamente allí donde se encadena todo.

La idea es que las acciones o verbos que originan los cambios de estado del cliente en REST están completamente definidos. Es decir, REST propone un vocabulario de acciones fijo; que permite obtener recursos del servidor, que una vez interpretados por el cliente, hacen que este cambie de estado.

Esto último es lo que más diferencia a REST por ejemplo del tradicional SOAP. Ya que en SOAP, se le dice a cada desarrollador que defina un vocabulario nuevo y arbitrario de verbos, de acuerdo a los requerimientos de la aplicación (obtenerUsuarios(), almacenarOrden(…), etc. Todos sobreusando el verbo POST de HTTP). Paradójicamente, esto que siempre se vio como una gran ventaja, va en contravía con muchos de los aspectos inherentes del HTTP que es base de SOAP. Así que aspectos como la autenticación, caching, negociación de contenidos y demás, no se aprovechan.

Aunque hasta aquí todo lo ejemplifiqué usando HTTP, REST es un mecanismo que no depende de ese protocolo. Las aplicaciones REST pueden basarse en otros protocolos, siempre y cuando éstas provean un vocabulario uniforme preestablecido para las aplicaciones que se construirán sobre ella. Recordemos que la idea principal de REST es maximizar el uso de las capacidades predefinidas de la plataforma que los soporte. HTTP como tal, proporciona un rico vocabulario completamente establecido y estandarizado que se ajusta perfectamente a este objetivo. Es por esto, que hoy en día al hablar de REST uno automáticamente piensa en su implementación sobre HTTP.

Principios

REST se fundamenta en seis principios básicos:
• Cliente y Servidor plenamente identificados y separados
• No hay almacenamiento de estado en las transiciones (Stateless)
• Respuestas “cacheables” (Para mejorar las interacciones y el performance)
• Capas: Pueden haber varias capas de servidores intermedios
• Código por demanda: La funcionalidad de un cliente se puede extender con código trasmitido por el servidor (por ejemplo con JavaScript). Este es el único requerimiento opcional.
• Interfaz uniforme: La misma que se discutió anteriormente.

Objetivos

Los principios anteriormente mencionados, están diseñados para lograr los siguientes objetivos:
• Escalabilidad de componentes
• Generalidad de Interfaces
• Distribución Independiente de componentes
• Existencia de componentes intermediaros que reducen latencia, aumentan la seguridad y encapsulan sistemas de legado.

Recursos

Los recursos se definen como fuentes de información específica y son muy importantes en REST. Un cliente accede a los recursos que el servidor dispone. Imagine una aplicación empresarial con información de recursos humanos. En este caso, la lista de empleados es un recurso del servidor y para acceder a ellos, se requiere un identificador único (por ejemplo una URI), que es usado por el cliente para referenciarlo y una interfaz de comunicación estandarizada (por ejemplo HTTP). Obviamente, aparte de tener claro el objeto de una acción, se debe tener clara la acción a ejecutar sobre ese objeto. Así pues, una aplicación interactúa con los recursos sabiendo su identificador único y la acción a ejecutar sobre este. Por ejemplo: Recurso: Empleado con Id:3520. Acción: Borrar. Los recursos generalmente son transmitidos entre el servidor y el cliente usando formatos como HTML, XML o JSON. No obstante, los recursos también pueden ser imágenes, texto plano o cualquier otro formato.

Servicios Web REST

No son más que servicios WEB implementados usando HTTP y los principios de REST que comprenden una colección de recursos de acuerdo a los siguientes aspectos:

• Una URI base para el nombre del servicio: https://example.com/miservicio/
• El tipo MIME de los datos soportados por el servicio
• El conjunto de operaciones soportadas.
• En REST sobre HTTP, lo más normal es tener estas operaciones
  • POST: Crea nuevos recursos. Como retorno, se ofrece el ID automáticamente creado
  • GET: Lista un recurso
  • PUT: Reemplaza un recurso con otro (Útil para el update)
  • DELETE: Elimina un recurso

Entonces por ejemplo si se quisiera eliminar el empleado con ID 3520 se haría un request con DELETE a la siguiente URL desde el cliente:/span>
https://example.com/miservicio/empleados/3520

Conclusión

REST, que es una arquitectura y no un protocolo como SOAP, se basa en acciones sobre recursos, para permitir la interacción de un cliente con un servidor. La implementación sobre HTTP es la más común y ha permitido la creación de otras tecnologías. Por ejemplo Microsoft, que se ha basado en este tipo de implementación REST para generar el estándar OData (Open Data) sobre el cual se construyó WCF Data Services (antes conocido como ADO.NET Data Services), y que permite simplificar el acceso interoperable a las capas de datos en aplicaciones n-tier.