Servicios web basados en REST y orie­n­ta­dos a los recursos

La red in­fo­r­má­ti­ca mundial consta de muchos más co­m­po­ne­n­tes de los que en realidad perciben los usuarios de Internet cuando visitan una página web o hacen uso de una apli­ca­ción. No solo las personas, sino también las máquinas pueden acceder a los datos y co­n­te­ni­dos de los proyectos web más diversos. El requisito in­di­s­pe­n­sa­ble es que los gestores hagan que sus proyectos sean ac­ce­si­bles a otras apli­ca­cio­nes, poniendo a di­s­po­si­ción el servicio web co­rre­s­po­n­die­n­te. Un buen ejemplo es Twitter, donde gracias a un servicio web pa­r­ti­cu­lar, cualquier apli­ca­ción puede leer o incluso escribir tuits en nombre de los usuarios.

Existen di­fe­re­n­tes técnicas para im­ple­me­n­tar un servicio como este, como, por ejemplo, el protocolo de llamada a pro­ce­di­mie­n­to remoto (Remote Procedure Call, RPC), el protocolo de red SOAP o el paradigma de pro­gra­ma­ción Re­pre­se­n­ta­tio­nal State Transfer (REST), que aparece detallado a co­n­ti­nua­ción.

El término Re­pre­se­n­ta­tio­nal State Transfer (tra­n­s­fe­re­n­cia de estado re­pre­se­n­ta­cio­nal) nace en el 2000 con la tesis doctoral de Roy Fielding, uno de los pri­n­ci­pa­les de­sa­rro­lla­do­res de numerosos es­tá­n­da­res web. Fielding describe la ar­qui­te­c­tu­ra en la que se basa la World Wide Web (protocolo HTTP, ana­li­za­dor HTML y XML, servidor web y de apli­ca­cio­nes, etc.) de forma abstracta. Sin embargo, la ar­qui­te­c­tu­ra de REST no depende, en principio, de pro­to­co­los es­pe­cí­fi­cos y su concepto central son recursos que, según Fielding, han de cumplir los si­guie­n­tes re­qui­si­tos:

• Di­re­c­cio­na­bi­li­dad: cada recurso, p. ej., un pedido, un producto o un artículo tiene que poder ide­n­ti­fi­car­se mediante un ide­n­ti­fi­ca­dor 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 no­r­ma­li­za­dos. Algunos ejemplos son los métodos HTTP como “GET”, “POST” o “PUT”.

• Es­tru­c­tu­ra cliente-servidor: en general, el principio cliente-servidor se aplica cuando el servidor pone a di­s­po­si­ción un servicio cada vez que el cliente lo reclama.

• Ausencia de estado: la co­mu­ni­ca­ción entre servidor y cliente es un proceso sin estado. En otras palabras: los mensajes que se in­te­r­ca­m­bian contienen toda la in­fo­r­ma­ción necesaria para en­te­n­de­r­la, por lo que el servidor no necesita guardar in­fo­r­ma­ció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á­ci­l­me­n­te es­ca­la­bles, ya que las so­li­ci­tu­des en el marco de la di­s­tri­bu­ción de la carga se di­s­tri­bu­yen de manera sencilla por di­fe­re­n­tes se­r­vi­do­res.

• Variedad de re­pre­se­n­ta­cio­nes de los recursos: cada recurso puede pre­se­n­tar­se de di­fe­re­n­tes formas. En función de lo que el cliente exija, la in­fo­r­ma­ción entregada tendrá que estar di­s­po­ni­ble, por ejemplo, en di­fe­re­n­tes lenguajes o formatos, como HTML, JSON o XML.

• Hi­pe­r­me­dia: la puesta a di­s­po­si­ción de los recursos tiene lugar a través de hi­pe­r­me­dia, p. ej., en forma de atributos “href” y “src” en do­cu­me­n­tos HTML o de elementos JSON o XML para la interfaz co­rre­s­po­n­die­n­te. Por lo tanto, el cliente de una API REST navega según el principio de Hy­pe­r­me­dia as the Engine of Ap­pli­ca­tion State (HATEOAS) por medio de las di­re­c­cio­nes URL que facilita el servidor y que no requieren co­no­ci­mie­n­tos adi­cio­na­les sobre la interfaz.

Las estrictas normas de la ar­qui­te­c­tu­ra REST hacen posible el de­sa­rro­llo de servicios bien es­tru­c­tu­ra­dos, fáciles de integrar y que se comunican por medio de un protocolo no­r­ma­li­za­do (HTTP). Gracias a una es­tru­c­tu­ra orientada a los recursos, en la co­n­ce­p­ción de un REST we­b­se­r­vi­ce o servicio web REST la búsqueda de pro­to­co­los es­pe­cí­fi­cos para apli­ca­cio­nes no es necesaria, al contrario que en el caso de al­te­r­na­ti­vas como SOAP.  

En la rea­li­za­ción de un servicio REST entran en juego, fu­n­da­me­n­ta­l­me­n­te, 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 co­r­ta­fue­gos y, por otro, a que el protocolo de tra­n­s­fe­re­n­cia de hi­pe­r­te­x­to, que es un protocolo sin estado, tiene una es­tru­c­tu­ra en co­m­pa­ra­ción sencilla y no necesita im­ple­me­n­ta­cio­nes es­pe­cia­les. 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 im­ple­me­n­tan otros pro­to­co­los. El protocolo típico es WebDAV, que agrega los métodos COPY (copiar recurso), MOVE (mover recursos), LOCK (bloquear recurso), UNLOCK (de­s­blo­quear recurso) y MKCOL (crear di­re­c­to­rio).

A la hora de de­sa­rro­llar 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 ar­qui­te­c­tu­ra 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 po­si­bi­li­da­des de dicha ar­qui­te­c­tu­ra. El tra­ta­mie­n­to 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 si­guie­n­tes ejemplos:

• Servicios web con pro­ce­sa­mie­n­to de tra­n­sac­cio­nes: para llevar a cabo servicios con tra­n­sac­cio­nes es im­pre­s­ci­n­di­ble contar con un gestor de tra­n­sac­cio­nes. Como los recursos, debido a la falta de estado, se guardan siempre entre dos pe­ti­cio­nes sin in­fo­r­ma­ción adicional, es decir, sin sesión asignada, la im­ple­me­n­ta­ción con REST está limitada a dos po­si­bi­li­da­des:

1. Los recursos se diseñan de tal manera que las tra­n­sac­cio­nes pueden ser in­te­r­pre­ta­das en el marco de una solicitud.
2. Se crea un recurso que ad­mi­ni­s­tre las pe­ti­cio­nes para las tra­n­sac­cio­nes.  Cada solicitud puesto a di­s­po­si­ción de este recurso-gestor de tra­n­sac­cio­nes genera au­to­má­ti­ca­me­n­te otro recurso, ide­n­ti­fi­ca­do mediante un URI y que re­pre­se­n­ta una tra­n­sac­ción re­la­cio­na­da con él. Como co­n­se­cue­n­cia, los cambios que se realicen serán al­ma­ce­na­dos en forma de re­pre­se­n­ta­cio­nes del recurso. Una solicitud adicional hecha al gestor de tra­n­sac­cio­nes finaliza la tra­n­sac­ción.

• Servicios web asi­n­cró­ni­cos: para servicios web más es­pe­cí­fi­cos, se re­co­mie­n­da que la solicitud y su respuesta estén di­so­cia­das en el tiempo. Puesto que HTTP no ofrece en este caso ningún mecanismo, a los pro­vee­do­res de servicios tan solo les queda la opción de gestionar el pro­ce­sa­mie­n­to de las so­li­ci­tu­des por cuenta propia y de re­en­viar­las a pe­ti­cio­nes concretas de los usuarios.

• Servicios web con amplia in­te­ro­pe­ra­bi­li­dad: los servicios de Re­pre­se­n­ta­tio­nal State Transfer se di­s­ti­n­guen por su gran fle­xi­bi­li­dad. Esta resulta, por una parte, de la co­n­ce­n­tra­ción en un protocolo único y su­b­ya­ce­n­te y, por otra, de la di­re­c­cio­na­li­dad directa de cada uno de los recursos. Los clientes móviles, en concreto, se be­ne­fi­cian de los escasos re­qui­si­tos de la ar­qui­te­c­tu­ra REST y de la sencilla ac­ce­si­bi­li­dad de los recursos que hace que los bu­s­ca­do­res puedan en­co­n­trar­los sin problemas.  

La es­tru­c­tu­ra REST ofrece medios ex­ce­le­n­tes para la co­n­ce­p­ción e im­ple­me­n­ta­ción de todo tipo de servicios web. Gracias a que casi todos los di­s­po­si­ti­vos soportan HTTP, tanto los clientes móviles como los de es­cri­to­rio pueden trabajar con la interfaz de REST con facilidad y sin necesidad de realizar im­ple­me­n­ta­cio­nes adi­cio­na­les. El resultado son servicios web que so­r­pre­n­den gracias a un alto grado de:

• in­de­pe­n­de­n­cia de pla­ta­fo­r­ma,

• es­ca­la­bi­li­dad,

• re­n­di­mie­n­to,

• in­te­ro­pe­ra­bi­li­dad

• y fle­xi­bi­li­dad

Sin embargo, su uso requiere los co­no­ci­mie­n­tos co­rre­s­po­n­die­n­tes, pues la in­ter­ac­ción entre cada uno de los recursos sin estado se convierte en un proceso complejo. Los pri­n­ci­pios tan di­fe­re­n­tes y poco fre­cue­n­tes que sustentan a REST obligan a adaptarse a una forma co­m­ple­ta­me­n­te diferente de trabajar, es­pe­cia­l­me­n­te a aquellos aco­s­tu­m­bra­dos a al­te­r­na­ti­vas como el protocolo SOAP, aunque, al final, se dispone de un servicio aplicable a cualquier tipo de contexto.