¿Guía para elegir entre servicios REST vs SOAP?

Question

¿Alguien tiene enlaces a documentación o guías sobre cómo tomar la decisión entre REST vs.¿JABÓN?Entiendo ambos, pero estoy buscando algunas referencias sobre los puntos clave de decisión, por ejemplo, seguridad, que pueden hacer que se incline hacia uno u otro.

Answer 1

Primer golpe de Google Parece bastante completo.

Creo que el problema aquí es que hay demasiados defensores de uno u otro, puede ser mejor buscar en Google y controlar mejor los pros y los contras y tomar su propia decisión.

Sé que suena un poco aburrido, pero en última instancia, este tipo de decisiones de diseño recaen en el desarrollador/arquitecto que trabaja en ello, y El 99% de las veces, el dominio del problema será el factor decisivo (o al menos debería serlo), no una guía en la red.

Answer 2

El estándar SOAP (Protocolo simple de acceso a objetos), un lenguaje XML que define una arquitectura de mensajes y formatos de mensajes, es utilizado por servicios web y contiene una descripción de las operaciones.WSDL es un lenguaje basado en XML para describir servicios web y cómo acceder a ellos.se ejecutará en SMTP, HTTP, FTP, etc.Requiere soporte de middleware, mecanismos bien definidos para definir servicios como WSDL+XSD, WS-Policy SOAP devolverá datos basados ​​en XML. SOAP proporciona estándares de seguridad y confiabilidad.

Servicios web de transferencia de estado representacional (RESTful).son Servicios Web de segunda generación.Los servicios web RESTful se comunican a través de HTTP que los servicios basados ​​en SOAP y no requieren mensajes XML ni definiciones de API de servicio WSDL.para REST no se requiere middleware, solo se necesita soporte HTTP. Estándar WADL, REST puede devolver XML, texto sin formato, JSON, HTML, etc.

Es más fácil para muchos tipos de clientes consumir servicios web RESTful y al mismo tiempo permitir que el lado del servidor evolucione y escale.Los clientes pueden optar por consumir algunos o todos los aspectos del servicio y combinarlo con otros servicios basados ​​en la web.

REST uses standard HTTP so it is simplerto creating clients, developing APIs 
REST permits many different data formats like XML, plain text, JSON, HTML where  as  SOAP only permits XML.
REST has better performance and scalability.
Rest and can be cached and SOAP can't 
Built-in error handling where SOAP has No error handling
REST is particularly useful PDA and other mobile devices.

REST son servicios fáciles de integrar con sitios web existentes.

SOAP tiene un conjunto de protocolos que proporcionan estándares de seguridad y confiabilidad, entre otras cosas, e interoperan con otros clientes y servidores que cumplen con WS.Los servicios web SOAP (como JAX-WS) son útiles para manejar el procesamiento y la invocación asincrónicos.

Para SOAP de API complejas será más útil.

Answer 3

Creo que tanto REST como SOAP se pueden usar para implementar una funcionalidad similar, pero en general se debe usar SOAP cuando se necesita una característica particular de SOAP, y las ventajas de REST lo convierten generalmente en la mejor opción.Sin embargo, tanto REST como SOAP a menudo se denominan "servicios web" y a menudo se utiliza uno en lugar del otro, pero son enfoques totalmente diferentes.REST es un estilo arquitectónico para crear aplicaciones cliente-servidor.SOAP es una especificación de protocolo para el intercambio de datos entre dos puntos finales.

Estoy muy de acuerdo con +Rob Cooper en su publicación.Sí, hay tantos defensores.He enumerado el diferencia entre jabón y reposo.

Answer 4

Hay un buen diagrama de flujo que puede utilizar para decidir entre REST y SOAP.

Enlace 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

Los otros dos factores que utilizo para tomar esta decisión son:

1) ¿Los clientes del Servicio requerirán tipos de medios distintos de XML (por ejemplo, JSON)?En caso afirmativo, utilice REST.

2) ¿El cliente del Servicio siempre será una Aplicación/Servidor (p. ej.no es un cliente RIA o AJAX).En caso negativo, esto se inclina hacia REST ya que es más fácil consumir servicios REST cuando se usa AJAX.