SOAP vs REST

Desde hace dos años he estado trabajando en proyectos de integración basados en arquitecturas orientadas en servicios (SOA) y bus de servicios empresariales. Una de las características mas resaltante de SOA, es que esta basada en contratos, donde el proveedor establece las reglas de comunicación, el transporte, y los datos de estrada y salida que serán intercambiados por ambas partes.

Los beneficios son grandes, se incentiva la reusabilidad, la independencia de la tecnología de implementación, el manejo de contratos, etc., y muchas otras.

Dentro del mundo Open Source, proyectos como Axis y Xfire nos permiten exponer un componente java como un servicio Web (Web Services), mediante un contrato establecido en un archivo WSDL, el cual describe las reglas e interacciones posibles entre el proveedor y el consumidor. Por lo general, estas tecnologías disponen de componentes de software para crear clientes que consumen los servicios, a partir de los archivos WSDL (WSDL a Java, o WSDL a .Net, o WSDL a C++) conocidos como proxys.

Este tipo de arquitectura, tiene técnicamente algunos inconvenientes, que deben ser manejadas por los arquitectos de software.

La existencia de un contrato, establece algunas brechas con una situación existente en todas las organizaciones "El Cambio". Los clientes que consumen un servicio, están atados a un contrato de operaciones y mensajes (request y respose). Esta esquema no es muy flexible, porque la implementación esta acoplada al contrato, lo que indica que si efectuamos un cambio en el mismo, por ejemplo, la adicción de un nuevo atributo al contrato, las implementaciones se rompen, afectando a todos los clientes que consumen el servicio. En conclusión "Un cambio en el contrato de un servicio, afecta a todas las implementaciones de los clientes, técnicamente tendrán que regenerar los proxys para cada servicio”.

Hace poco tuve que intentar desarrollar un modelo que permitiera desacoplar los proxys ante cambios de los contratos. En la mayoría de las implementaciones el proceso de deserealizacion (xml a objeto), es donde falla, indicando que se incluye un nuevo elemento que no puede ser mapeado a un atributo de una clase java. Este inconveniente puede resolverse en Axis, implementando un proceso de deserealizacion customizado para que no tome en cuenta atributos nuevos.

En otros escenarios, donde el desarrollador no tiene control de las generaciones de estos proxys, la cuestión se complica.

Una alternativa, es el tipo de arquitectura REST, donde a diferencia del modelo anterior, el contrato solo es de entrada, por ende tiende a ser mas flexible y apropiado para el "El Cambio".

REST (Representational State Transfer), es un estilo de arquitectura que ofrece un buen desempeño, escalabilidad y abstracción de recursos, donde cada petición HTTP contiene toda la información necesaria para responder a la petición, sin necesidad que el cliente ni el servidor tenga que recordar el estado de su comunicación.

REST se diferencia de los Web Services por:

1. REST ofrece recursos y representaciones variadas por ejemplo, xml, html, text, pdf, binarios, etc. y permite la utilización de links entre diversos recursos, por el contrario los Web Services solo manejan XML como documentos de intercambio basados en el protocolo SOAP.
2. Los servicios web no están focalizados en recursos, sino en operaciones.
3. REST depende directamente del protocolo HTTP (Hypertext Transfer Protocol), este expone siempre la misma interfase a todos los consumidores, mediante operaciones bien definidas: POST, GET, PUT y DELETE. Desde el punto de vista REST es mucho más escalable que los Web Services donde tenemos diversas interfaces, es decir diversas operaciones.
4. REST, expone sus recursos a través de un URI (Uniform Resource Identifier); y permite cambiar el estado de un recurso a través de una de operaciones genéricas para todos los consumidores.
   

Recomendaciones

1. Lo mejor es utilizar REST cuando sea necesario tener representación distinta a XML.
2. Si el criterio de la escalabilidad tiene mucho peso dentro del blueprint de arquitectura, REST es la mejor opción porque permite que todos los recursos presenten la misma interfase a los clientes.
3. SOA y Web Services, están apoyados sobre estándares y especificaciones de amplia madurez por ejemplo WS-Security, REST no cuenta por ejemplo con una amplia gama de estándares.
4. Los Web Services pueden soportar mas protocolos de transporte como JMS, SOAP, etc. REST solo conoce HTTP.
5. Si tenemos que ofrecer servicios de la sindicación de por RSS o ATOM, REST es la mejor opción.
   

En conclusión, ambas aproximaciones tienen sus ventajas y desventajas, el papel fundamental de arquitecto evaluar su utilización dentro del escenario mas apropiado para obtener un modelo de arquitectura ágil y eficiente.

Una referencia...