Servicios web basados en REST y orientados a los recursos

La red informática mundial consta de muchos más componentes de los que en realidad perciben los usuarios de Internet cuando visitan una página web o hacen uso de una aplicación. No solo las personas, sino también las máquinas pueden acceder a los datos y contenidos de los proyectos web más diversos. El requisito indispensable es que los gestores hagan que sus proyectos sean accesibles a otras aplicaciones, poniendo a disposición el servicio web correspondiente. Un buen ejemplo es Twitter, donde gracias a un servicio web particular, cualquier aplicación puede leer o incluso escribir tuits en nombre de los usuarios.

Existen diferentes técnicas para implementar un servicio como este, como, por ejemplo, el protocolo de llamada a procedimiento remoto (Remote Procedure Call, RPC), el protocolo de red SOAP o el paradigma de programación Representational State Transfer (REST), que aparece detallado a continuación.

El término Representational State Transfer (transferencia de estado representacional) nace en el 2000 con la tesis doctoral de Roy Fielding, uno de los principales desarrolladores de numerosos estándares web. Fielding describe la arquitectura en la que se basa la World Wide Web (protocolo HTTP, analizador HTML y XML, servidor web y de aplicaciones, etc.) de forma abstracta. Sin embargo, la arquitectura de REST no depende, en principio, de protocolos específicos y su concepto central son recursos que, según Fielding, han de cumplir los siguientes requisitos:

• Direccionabilidad: cada recurso, p. ej., un pedido, un producto o un artículo tiene que poder identificarse mediante un identificador de recursos uniforme o URI.

• Interfaz uniforme: se tiene que acceder a cada recurso de manera sencilla y unitaria con la ayuda de métodos normalizados. Algunos ejemplos son los métodos HTTP como “GET”, “POST” o “PUT”.

• Estructura cliente-servidor: en general, el principio cliente-servidor se aplica cuando el servidor pone a disposición un servicio cada vez que el cliente lo reclama.

• Ausencia de estado: la comunicación entre servidor y cliente es un proceso sin estado. En otras palabras: los mensajes que se intercambian contienen toda la información necesaria para entenderla, por lo que el servidor no necesita guardar información adicional entre dos mensajes en forma de sesiones, por mencionar un ejemplo. La ausencia de estado hace que los servicios de REST sean fácilmente escalables, ya que las solicitudes en el marco de la distribución de la carga se distribuyen de manera sencilla por diferentes servidores.

• Variedad de representaciones de los recursos: cada recurso puede presentarse de diferentes formas. En función de lo que el cliente exija, la información entregada tendrá que estar disponible, por ejemplo, en diferentes lenguajes o formatos, como HTML, JSON o XML.

• Hipermedia: la puesta a disposición de los recursos tiene lugar a través de hipermedia, p. ej., en forma de atributos “href” y “src” en documentos HTML o de elementos JSON o XML para la interfaz correspondiente. Por lo tanto, el cliente de una API REST navega según el principio de Hypermedia as the Engine of Application State (HATEOAS) por medio de las direcciones URL que facilita el servidor y que no requieren conocimientos adicionales sobre la interfaz.

Las estrictas normas de la arquitectura REST hacen posible el desarrollo de servicios bien estructurados, fáciles de integrar y que se comunican por medio de un protocolo normalizado (HTTP). Gracias a una estructura orientada a los recursos, en la concepción de un REST webservice o servicio web REST la búsqueda de protocolos específicos para aplicaciones no es necesaria, al contrario que en el caso de alternativas como SOAP.  

En la realización de un servicio REST entran en juego, fundamentalmente, el protocolo HTTP y su versión cifrada HTTPS. Ello se debe, por un lado, a su gran difusión, por la cual está abierto en cualquier cortafuegos y, por otro, a que el protocolo de transferencia de hipertexto, que es un protocolo sin estado, tiene una estructura en comparación sencilla y no necesita implementaciones especiales. Además, el estándar HTTP define una gama completa de comandos por medio de los que se puede acceder a los recursos:

La gama de comandos puede aumentar si se implementan otros protocolos. El protocolo típico es WebDAV, que agrega los métodos COPY (copiar recurso), MOVE (mover recursos), LOCK (bloquear recurso), UNLOCK (desbloquear recurso) y MKCOL (crear directorio).

A la hora de desarrollar un servicio REST vía HTTP, los comandos más típicos son GET, POST, PUT/PATCH y DELETE, lo que pone de relieve que su arquitectura solo es apta para la gestión sencilla de datos. Además, el principio de la ausencia de estado en los recursos de REST parece limitar mucho las posibilidades de dicha arquitectura. El tratamiento adecuado de los recursos, sin embargo, hace que la REST interface o interfaz de REST haga posible mucho más que la mera inclusión de conjuntos de datos, tal y como se muestra en los siguientes ejemplos:

• Servicios web con procesamiento de transacciones: para llevar a cabo servicios con transacciones es imprescindible contar con un gestor de transacciones. Como los recursos, debido a la falta de estado, se guardan siempre entre dos peticiones sin información adicional, es decir, sin sesión asignada, la implementación con REST está limitada a dos posibilidades:

1. Los recursos se diseñan de tal manera que las transacciones pueden ser interpretadas en el marco de una solicitud.
2. Se crea un recurso que administre las peticiones para las transacciones.  Cada solicitud puesto a disposición de este recurso-gestor de transacciones genera automáticamente otro recurso, identificado mediante un URI y que representa una transacción relacionada con él. Como consecuencia, los cambios que se realicen serán almacenados en forma de representaciones del recurso. Una solicitud adicional hecha al gestor de transacciones finaliza la transacción.

• Servicios web asincrónicos: para servicios web más específicos, se recomienda que la solicitud y su respuesta estén disociadas en el tiempo. Puesto que HTTP no ofrece en este caso ningún mecanismo, a los proveedores de servicios tan solo les queda la opción de gestionar el procesamiento de las solicitudes por cuenta propia y de reenviarlas a peticiones concretas de los usuarios.

• Servicios web con amplia interoperabilidad: los servicios de Representational State Transfer se distinguen por su gran flexibilidad. Esta resulta, por una parte, de la concentración en un protocolo único y subyacente y, por otra, de la direccionalidad directa de cada uno de los recursos. Los clientes móviles, en concreto, se benefician de los escasos requisitos de la arquitectura REST y de la sencilla accesibilidad de los recursos que hace que los buscadores puedan encontrarlos sin problemas.  

La estructura REST ofrece medios excelentes para la concepción e implementación de todo tipo de servicios web. Gracias a que casi todos los dispositivos soportan HTTP, tanto los clientes móviles como los de escritorio pueden trabajar con la interfaz de REST con facilidad y sin necesidad de realizar implementaciones adicionales. El resultado son servicios web que sorprenden gracias a un alto grado de:

• independencia de plataforma,

• escalabilidad,

• rendimiento,

• interoperabilidad

• y flexibilidad

Sin embargo, su uso requiere los conocimientos correspondientes, pues la interacción entre cada uno de los recursos sin estado se convierte en un proceso complejo. Los principios tan diferentes y poco frecuentes que sustentan a REST obligan a adaptarse a una forma completamente diferente de trabajar, especialmente a aquellos acostumbrados a alternativas como el protocolo SOAP, aunque, al final, se dispone de un servicio aplicable a cualquier tipo de contexto.