Espacio SOA

REST (Representational State Transfer) puede ser considerado según algunos expertos como algo importante para el futuro de SOA en muchos aspectos.

Vamos a explicar un poco que es REST, como funciona y porqué podría convertirse en algo cotidiano (en un futuro no muy lejano) para los Arquitectos SOA si las previsiones son ciertas.

El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo.

REST es, según algunos, la mejor manera de crear interfaces para servicios web que promulguen ante todo el débil acoplamiento (como una de las máximas y prioritarias definiciones de un servicio web).
REST depende directamente del protocolo HTTP (Hypertext Transfer Protocol) en un sentido de petición-respuesta (request-response) utilizando un conjunto
simple y pequeño de operaciones bien definidas: POST, GET, PUT y DELETE.
En REST, un recurso es expuesto a través de una URI (Uniform Resource Identifier); y la idea es que REST permita cambiar el estado de un recurso a través de una de las 4 operaciones antes descritas.

Es importante diferenciar REST de RPC (Remote Procedure Call); ya que éste último lo que hace es invocar un procedimiento en un sistema remoto.

Pongamos un ejemplo para verlo mejor:

1. REST nos permite llamar a un recurso "Libro" que puede tener expuesto cientos de URI’s. Por ejemplo, http://miweb/libro/ciencia-ficcion/viaje-a-la-luna se refiere a un registro o recurso concreto de Libro dentro de la categoría de ciencia ficción.
2. Para modificar la información en dicho registro, REST utiliza POST o PUT para enviar un XML en dicha URI y posteriormente conseguir la información a través de GET.

Lo primordial en este ejemplo, es darse cuenta de que lo importante es el "nombre", no el "verbo" (como es el caso de RPC o servicios web tradicionales). Si utilizaramos RPC, lo más parecido al ejemplo de REST, sería llamar a una función getLibro() al que se la pasaría un identificador de dicho libro. El hecho de utilizar REST simplifica mucho la forma de hacerlo.

Los servicios web no están focalizados en recursos, sino en operaciones. Podemos disponer de un servicio web con cientos de operaciones, cada una de las cuales especifica la manera en que se comportará ante una petición y como manejará el XML entrante para dar una respuesta concreta.

Es importante diferenciar un servicio web con multitud de operaciones (para borrado, modificación, petición, etc…) de multiples servicios web para implementar todas las operaciones posibles. Esta sería la diferencia más palpable entre estilo RPC y estilo documento (RPC-style vs. Document-style).
El caso de REST sería más próximo al estilo documento, ya que únicamente nos tenemos que encargar de enviar un XML a una URI definida para un conjunto mínimo de 4 operaciones. Aquí, la utilización de REST es mucho menos acoplada que la utilización de RPC, ya que se minimiza el impacto por cambios en la interfaz de datos intercambiados.

REST implica el cambio de estado de un recurso, pero sin definir la operación (son siempre 4 fijas). Pero lo que haga cada una de esas operaciones depende de la implementación final para cada recurso que se haga.

No obstante, REST no es la panacea: en ocasiones SOAP se antoja mejor que REST para dependiendo que implementación sea necesaria.

SOAP lleva siempre asociado la definición de servicio web. Y como tal, su definición a través de un WSDL.
REST por el contrario no ofrece esta posibilidad. REST es mucho más sencillo, es lo más optimo para simplificar una interfaz a utilizar por
consumidores externos (el ejemplo más claro lo tenemos con Google, que expone sus servicios web via REST y da como respuesta un xml con formato de
sindicación RSS o ATOM) o cachear resultados a nivel de recursos.
Pero si queremos implementar cosas más complejas necesitaremos SOAP: Por ejemplo, REST lleva asociado HTTP como único protocolo de transporte. Si tenemos necesidad de utilizar otro tipo de transporte como JMS, SOAP si es válido, pero no así el caso de REST.
Además, en niveles de seguridad, la pila WS-* (concretamente con su definición de WS-Security a nivel de mensaje) permite un mayor nivel de
securización que REST (que se implementa en caso de necesidad a nivel de HTTP como transporte).

REST, SOAP…. SOAP y REST. No creo que sean incompatibles ni que uno vaya a ser el ganador. Creo que ambos tienen su hueco y dependiendo de la necesidad será más recomendado utilizar uno u otro. Lo que si es claro, es que REST va a dar mucho que hablar de aquí a poco tiempo, de hecho se está utilizando ya ampliamente (la sindicación de blogs por RSS o ATOM utilizan REST; Google expone sus servicios web como REST, eBay y Amazon ofrece una interfaz REST para sus desarrolladores, etc…)

Links interesantes:

The benefits and limitations of REST
REST según Wikipedia
RestWiki
How I Explained REST to My Wife
Building Web Services the REST Way
REST for the Rest of Us
"Representational State Transfer (REST)" PhD dissertation by Roy T. Fielding