WebServices: SOAP vs REST: ¿Cual usar en cada caso?

Llevo prácticamente dos años, desde que empece en mi ultimo trabajo, estudiando servicios web y arquitecturas orientadas a servicios. Hasta el momento he creado arquitecturas SOA utilizando BPM (Business process management) para la comunicación e interoperabilidad de diferentes servicios(principalmente de tipo SOAP) con que cuenta cada sistema, y de esta forma creando la logica intermedia que es necesaria en cualquier infrastructura global de servicios.

Yo mismo me hago la pregunta cuando necesito crear un nuevo servicio web, ¿Que tipo de servicio crear? Por un lado me empuja mi mente estructura a pensar en servicios SOAP, donde tienes todo muy organizado, creas tu propio XSD, generas el WSDL y con dos click en el entorno de desarrollo tienes creado tu servicio web a la medida. Por otro lado me tira la tendencia actual del mercado, REST coge fuerza en detrimento de SOAP, todas las APIs importantes utilizando servicios REST (twitter, flickr, google, etc.), los framework javascript que conozco están en pleno auge con sus peticiones hacia servicios REST (jquery, mootools, etc.).

Empecemos por el principio: ¿Que es un servicio SOAP y un servicio REST?
SOAP:
– SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML
– Las operaciones son definidas como puertos WSDL
– Dirección única para todas las operaciones
– Componentes fuertemente acoplados
– Múltiples instancias del proceso comparten la misma operación
REST:
– Es un estilo de arquitectura de software para sistemas hipermedias distribuidos tales como la Web. Se centra en los estándares HTTP y XML
– Paradigma creado en la tesis doctoral de Roy Fielding en 2000, quien es uno de los principales autores de la especificación de HTTP.
– REST se refiere únicamente a una colección de principios para el diseño de arquitecturas en red que se centran en como los recursos son definidos y diseccionados.
– El objetivo principal es transmitir un conjunto de datos de un domino sobre el protocolo HTTP sin la necesidad de contar con una capa adicional, como hace SOAP.
– Las operaciones se definen como mensajes
– Una dirección única para cada instancia del proceso
– Componentes débilmente acoplados

¿Donde es mejor utilizar SOAP?
– Cuando se establece un contrato formal donde se describe todas las funciones de la interfaz.  El lenguje WSDL(Web Services Description Language) nos permite definir cualquier detalle.
– Cuando es necesario que la arquitectura aborde requerimientos complejos no funcionales.Por ejemplo en el uso de transacciones, seguridad o direccionamiento, casos donde es necesario mantener la información contextual y el estado.
– En casos donde la arquitectura necesita manejar un procesado asíncrono debido al tiempo que necesita para realizar una parte del procesado de la petición.

¿Donde es mejor utilizar REST?
– Cuando el servicio web no necesita tener estado.
– Cuando buscamos mejorar el rendimiento, una infraestructura caching puede mejorarlo.
– En momentos donde el productor como el consumidor conocen el contexto y contenido que van a intercambiar.
–  REST es muy util para el consumo como servicio web en dispositivos moviles donde tenemos escasos recursos.
– REST es un acierto en la creación de servicios que se utilizaran de agregadores de información en mashup o sitios web existentes. También cuando usemos tecnologías como AJAX o framewoks javascript.

¿Estado actual del mercado, a nivel de APIs?

Referencia de la imagen