¿Cuáles son los factores decisivos para elegir exponer un servicio web como un servicio SOAP o REST?

Por lo que puedo ver, el consumo de SOAP requiere una pila de SOAP, por lo que es más difícil para sus clientes consumir, es decir, deben asegurarse de tener una pila de SOAP en su lugar que formatee correctamente los datos POST y los encabezados y luego le devuelva algunos estructura de datos, mientras que con REST solo hace una solicitud HTTP GET con los argumentos en la cadena de consulta y recupera un texto que creo que probablemente sea XML.

Entonces, ¿qué le proporciona la sobrecarga / complejidad adicional de SOAP, cuándo lo necesita y cuándo podría y debería prescindir de él?

He implementado una API REST antes y realmente me gustó. En general, cuando implementa REST sobre SOAP, su cliente / servidor es más ortogonal, lo que significa que puede cambiar mucho más libremente el servidor sin afectar a su (s) cliente (s). Esta ortogonalidad se debe al uso de una comunicación más abstracta y bien definida a través de verbos HTTP. Además, el uso de hipervínculos incrustados en sus respuestas REST hace que sea más fácil extender y hacer crecer su API relativamente sin problemas. Se supone que los clientes deben seguir estos enlaces incrustados para obtener nuevos recursos, como un ser humano seguiría los enlaces en una página web para 'profundizar' para obtener más información.

Dicho esto, tuve algunos compañeros de trabajo a quienes les dijeron que tenían que usar SOAP y se quejaron de eso todo el tiempo. Así que empecé a investigar los dos un poco más en detalle.

En general, lo que encontré es que REST es muy adecuado para aplicaciones altamente distribuidas , cuando tienes cientos, miles o millones de clientes . Una razón es la ortogonalidad mencionada anteriormente, otra es el almacenamiento en caché que obtienes de forma gratuita ya que estás utilizando HTTP.

SOAP puede ser el camino más rápido cuando necesita una API más pequeña para un cliente o dos rápidamente y no está demasiado preocupado por la escalabilidad. También podría encajar mejor si no tiene una arquitectura estructurada en torno a los recursos , ya que puede llevarle algún tiempo reestructurar su aplicación para incluso poder implementar REST.

Puede ser un punto menor, pero REST está completamente basado en HTTP.

SOAP no requiere HTTP, y puede usar el transporte que desee.

Los mensajes SOAP se pueden enrutar de forma asíncrona y confiable, mientras que REST es prácticamente un paradigma sincrónico.

REST no le dice nada sobre cómo deberían ser los datos que envía y recibe. Existe WADL, pero en su mayoría confía en que la documentación de la API sea correcta. SOAP tiene tecnologías circus de XML para hacer que la descripción de datos sea menos propensa a errores. WSDL, Esquema ...

Al final del día, REST básicamente le proporciona un sistema de archivos basado en HTTP. Si su sistema puede encajar en ese paradigma, entonces podría ser una buena opción.

Entonces, ¿qué le proporciona la sobrecarga / complejidad adicional de SOAP, cuándo lo necesita y cuándo podría y debería prescindir de él?

La mayor diferencia entre los dos es que se supone que REST no tiene estado, mientras que SOAP no lo es . En la práctica, muchas implementaciones de REST implementan algún estado en la sesión a través de algo como OAuth.

Otra diferencia es que REST está muy orientado hacia los "recursos" o los nombres . Interactúa con los recursos a través de operaciones CRUD. Cualquier cosa que no se ajuste a este paradigma se vuelve engorrosa y torpe.

SOAP, por otro lado, es solo un protocolo RPC (llamada a procedimiento remoto) . No viene con un paradigma, es solo la capa de transporte.

REST también usa la publicación. De hecho, cuando se usa REST, los verbos http le indican qué operación está sucediendo.

REST y SOAP son solo estándares diferentes para pasar datos a través de Internet.

Habiendo usado ambos, generalmente recomendaría usar REST en lugar de SOAP a menos que sepa que las personas que van a consumir su servicio web están usando .net y Visual Studio. En general, es mucho más fácil consumir un servicio web REST, excepto con .net VS, que hace la mayor parte del trabajo por usted cuando usa SOAP.

Una cosa que mencionaría es la interoperabilidad: si va a llamar a su servicio desde una aplicación escrita en .NET y el servidor está escrito en Java (o cualquier otra combinación), elija REST. He visto demasiadas incompatibilidades leves entre las implementaciones de SOAP para molestarme en considerarlo más.

Si solo desea una guía visual simple que lo ayude a medir SOAP y REST según los requisitos de sus aplicaciones ...

Vijay Prasad Gupta ha elaborado un diagrama de flujo simple y útil.

Enlace directo al diagrama de flujo: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit

Enlace al artículo: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs

Ahora es 2015. Esperaba que SOAP ya haya muerto, pero aún perdura como un mal olor. Para cualquier cosa que no sea la más básica de las aplicaciones de "ejemplo", la integración con un servicio SOAP está llena de desafíos. Es una arquitectura compleja, con muchas opciones en múltiples niveles, combinada con las peculiaridades de múltiples implementaciones e incompatibilidades sutiles (y no tan sutiles). Nunca he tenido una buena experiencia con eso. REST, por otro lado, es muy sencillo: todos entienden HTTP. Para la mayoría de los casos, JSON tiene mucha más utilidad que XML InfoSet.

Para darle una idea de la complejidad de SOAP, intente integrar una biblioteca SOAP en su proyecto. Para Java, el cliente Apache Axis2 más básico (que utiliza un enlace de datos ADB simple) incorpora 23 nuevos JAR. ¡Veintitres! 20 MB de hinchazón de la biblioteca. CXF es similar: 21 JAR, la última vez que conté.

Si realmente quisieras, puedes hacer REST con una simple biblioteca HTTP.