REST vs SOAP

Primero se debe tener claro que es cada cosa... escuchando alguna plática de gurús BPM con tu abuela, me di cuenta que hay cosas que creo están mal interpretadas, pero bueno me ha pasado nos pasa a todos.

No hay problema... el caso es que en ocasiones los términos pueden llegar a confundir y hacer que tomemos una opción inadecuada frente a x situación.

No me hagas pensar!

SOA (Service Oriented Architecture) es un concepto que refiere a un tipo particular de paradigma de arquitecturas de software.

Permite la creación de una arquitectura que se integra -o forma parte- de sistemas de información y/o aplicaciones que pueden llegar a ser bastante escalables, que permiten modelar todo el proceso de negocio de alguna organización, además es capaz de exponer e invocar servicios web, lo cual lleva a tener una rápida, práctica y, en general, una fácil integración de nuestra información. 

Para hacer analogía, la POO trabaja sobre aplicaciones construidas bajo un conjunto de librerías de clases -como podría ser un Framework-. Por el contrario, SOA se centra en sistemas que se construyen basándose en un conjunto de servicios independientes y autónomos.

¿Y con que se come ?

REST (Representational State Transfer) y SOAP (Simple Object Access Protocol) es como comparar peras y manzanas. Sin embargo, representan dos tipos diferentes -muy diferentes- para la implementación de una arquitectura SOA.

REST es un patrón de arquitectura construido bajo verbos simples que se adaptan bastante fácil con HTTP.

A diferencia, SOAP es un protocolo de mensajería basado en XML (mensajes SOAP con una estructura XML) que puede utilizarse por una variedad de protocolos de transporte, incluso el mismo HTTP.

¿Porqué son diferentes?

La principal diferencia entre el patrón REST y el protocolo SOAP, es la forma en la que se mantienen los diferentes estados por los que una aplicación pasa durante su vida. 

Con SOAP, el movimiento por los diferentes estados se realiza interactuando con un extremo único del servicio que puede encapsular y proporcionar acceso a muchas operaciones y tipos de mensaje. Por el contrario, con REST, se permite un número limitado de operaciones y dichas operaciones se aplican a recursos representados y direccionados por direcciones HTTP (URI). Los mensajes capturan el estado actual o el requerido del recurso. Por consecuencia, REST se integra bastante bien con aplicaciones Web donde se puede hacer uso de HTTP para tipos de datos que no son XML (o que no pueden serlo).

REST

1.- La arquitectura encaja de manera natural con HTTP.

2.- Necesario para clientes donde la capacidad es muy limitada (Escenarios JavaScript)

3.- No hay necesidad de Proxys (como en SOAP) para las conversiones y demás.

4.- Trata con acceso a recursos

REST - SOAP

5.- Operaciones remotas (una de las finalidades de los servicios web)

6.- Acceso a recursos remotos (más de lo anterior)

7.- Interoperable (otra de las finalidades de los servicios web)

SOAP

8.- El cifrado es a nivel de mensaje

9.- Dispone de ruteadores o intermediarios

10.- Reeegularmente (no creo que siempre) el envío de mensajes es confiable.

11.- Políticas de control (Diferentes perfiles)

12.- Basado en acciones

En resumen:

Ventajas de REST

• Está totalmente bajo especificaciones del protocolo HTTP, en donde todo actúa como un recurso, ni siquiera los servicios se escapan, se trata el mensaje igual como si fuera alguna imagen, uno o varios elementos HTML, etc. 
• No es tan estricto como SOAP, los datos pueden mantenerse estrictamente o de forma desacoplada, mediante la URI.
• Los recursos pueden consumirse fácilmente desde JavaScript (La mayoría de las aplicaciones que utilizan OpenId o el protocolo OAuth utilizan JavaScript para realizar llamadas con REST, por ejemplo twitter)
• Los mensajes son bastante ligeros, el rendimiento y la escalabilidad no deberían ser problema y cuando uno está acostumbrado a trabajar en "Internet", esto es de vida o muerte.
• REST no se queja, puede utilizar XML o JSON para el formato de los datos.

Desventajas de REST

• Si se trata de trabajar con objetos fuertemente tipados, tipo =P, en el código de servidor, es algo tedioso incluso difícil, pero esto también depende de otras situaciones.
• No creo (no lo sé) que funcione bien con aplicaciones de alto rendimiento y basadas en tiempo real. Por ejemplo, algún sistema para ingeniería industrial que arroje constantemente datos y mas datos para generar estadísticas.

Ventajas de SOAP

• Trabaja bien con datos, los mensajes y las comunicaciones están bien estructurados.
• Dispone de proxys fuertemente tipados.
• Funciona sobre diferentes protocolos, no solamente HTTP (como en REST) si no también sobre TCP, NamedPipes, MSMQ, etc. aunque el uso de estos no es tan bueno si se trata de estandarizar en Internet.

Desventajas de SOAP

• Los mensajes generados por SOAP no se pueden cachear (¿o si?)
• En JavaScript.. olvídate de SOAP.

¿Y entonces cuál?

No sé.. depende..

SOAP se ajusta muy bien para arquitecturas SOA implementadas dentro de aplicaciones con arquitecturas N-Layer. Además, SOAP gestiona aspectos de seguridad y direccionamiento mediante su implementación interna. También, funciona mucho mejor que REST con otro tipo de protocolos. Aunque, como comentaba, pierde "estandarización" pero si se trata dentro de una intranet donde los sistemas están controlados, creo que SOAP es la mejor opción.

Por el contrario, REST es normalmente mas adecuada para servicios distribuidos públicamente en Internet o en casos donde los consumidores son desconocidos (como el caso de implementaciones de OAuth).

REST es stateless por su naturaleza (HTTP), esto significa que cada petición individual enviada desde el cliente al servidor debe contener toda la información necesaria para entender la petición puesto que el servidor no almacenará datos de estado de sesión, o alguna mierd* cosa similar.

En definitiva, ambos protocolos permiten intercambiar datos haciendo uso de verbos y cada uno tiene sus desventajas frente al rendimiento y al ser escalables...

Al final, cada quien lo que se le antoje =P