¿Comparar y contrastar los servicios web REST y SOAP?

Question

Actualmente descubro que lo similar es usar el protocolo de internet (HTTP) para intercambiar datos entre el consumidor y el proveedor.

La diferencia es:

1. SOAP es un protocolo de mensajes basado en XML, mientras que el resto es un estilo arquitectónico
2. de SOAP utiliza WSDL para la comunicación entre el consumidor y el proveedor, mientras que resto sólo utiliza XML o JSON para enviar y recibir datos
3. de SOAP invoca servicios llamando método RPC, RESTO simplemente llama a los servicios a través de ruta URL
4. SOAP no devolver un resultado legible por humanos, mientras RESTO resultado se puede leer con apenas es XML o JSON sencillo
5. de SOAP no es sólo a través de HTTP, que también utiliza otros protocolos como SMTP, FTP, etc., el resto es sólo sobre HTTP

Eso es todo lo que sé como las diferencias entre ellos. ¿Alguien podría corregirme y agregar más?

Answer 1

de SOAP WSDL utiliza para la comunicación por cierto del consumidor y el proveedor, mientras que resto sólo utiliza XML o JSON para enviar y recibir datos

WSDL define contrato entre el cliente y el servicio y es por su naturaleza estática. En el caso de un contrato REST, es algo complicado y está definido por HTTP, URI, Formatos de medios y Protocolo de coordinación específica de la aplicación. Es altamente dinámico a diferencia de WSDL.

SOAP no devolver un resultado legible por humanos, mientras RESTO resultado se puede leer con XML es simplemente o JSON

Esto no es cierto. Simple XML o JSON no son RESTful en absoluto. Ninguno de ellos define ningún control (es decir, enlaces y relaciones de enlaces, información de métodos, información de codificación, etc.) que está en contra de REST en cuanto a que los mensajes deben ser autónomos y coordinar la interacción entre el agente/cliente y el servicio.

Con vínculos + relaciones de enlace semántico, los clientes deben poder determinar cuál es el próximo paso de interacción y seguir estos enlaces y continuar la comunicación con el servicio.

No es necesario que los mensajes sean legibles por humanos, es posible usar un formato críptico y crear aplicaciones REST perfectamente válidas. No importa si el mensaje es legible o no.

Por lo tanto, XML simple (application/xml) o JSON (application/json) no son formatos suficientes para construir aplicaciones REST. Siempre es razonable usar un subconjunto de estos tipos de medios genéricos que tienen un fuerte significado semántico y ofrecen suficiente información de control (enlaces, etc.) para coordinar las interacciones entre el cliente y el servidor.

• Para más detalles sobre la información de control le recomiendo a leer esto: http://www.amundsen.com/hypermedia/hfactor/
• de Enlace Web: http://tools.ietf.org/html/rfc5988
• rel Registrados:

REST es sólo sobre HTTP

No es cierto, HTTP es el más utilizado y cuando hablamos de servicios web REST solo asumimos HTTP. HTTP define la interfaz con sus métodos (GET, POST, PUT, DELETE, PATCH, etc.) y varios encabezados que se pueden usar de manera uniforme para interactuar con los recursos. Esta uniformidad se puede lograr con otros protocolos también.

P.S. explicación muy simple, pero muy interesante de ocio: http://www.looah.com/source/view/2284

Answer 2

SOAP trae su propio protocolo y se enfoca en exponer partes de la lógica de aplicación (no datos) como servicios. SOAP expone las operaciones. SOAP se centra en el acceso a operaciones con nombre, cada una implementa una lógica comercial a través de diferentes interfaces.

Aunque SOAP se conoce comúnmente como "servicios web", este es un nombre inapropiado. SOAP tiene muy poco o nada que ver con la Web. REST proporciona verdaderos "servicios web" basados ​​en URI y HTTP.

A modo de ilustración, aquí hay algunas llamadas y su correspondiente hogar con comentarios.

getUser(User); 

Esta es una operación de descanso ya que está accediendo a un recurso (datos).

switchCategory(User, OldCategory, NewCategory) 

REST permite muchos formatos de datos diferentes, ya que SOAP solo permite XML. Si bien esto puede parecer que agrega complejidad a REST porque necesita manejar múltiples formatos, en mi experiencia, en realidad, ha sido bastante beneficioso. JSON generalmente se adapta mejor a los datos y analiza mucho más rápido. REST permite una mejor compatibilidad con los clientes del navegador debido a su compatibilidad con JSON.

Answer 3

En el día a día, las condiciones prácticas de programación, la mayor diferencia está en el hecho de que con el jabón que está trabajando con formatos de intercambio de datos estáticos y fuertemente definidos en tanto que con el descanso y el formato de intercambio de datos JSON es muy flexible en comparación. Por ejemplo, con SOAP puede validar que los datos intercambiados coinciden con un esquema XSD. Por lo tanto, el XSD sirve como un "contrato" sobre cómo el cliente y el servidor deben entender cómo deben estructurarse los datos que se intercambian.

datos JSON es normalmente no pasa alrededor de acuerdo con un formato muy definido (a menos que esté utilizando un marco que lo soporta, por ejemplo .. http://msdn.microsoft.com/en-us/library/jj870778.aspx o la aplicación de JSON-esquema).

En realidad, algunos (muchos/la mayoría) argumentan que la salsa secreta "dinámica" de JSON va en contra de la filosofía/cultura de constreñir por contratos de datos (Should JSON RESTful web services use data contract)

personas acostumbradas a trabajar en la dinámica Los lenguajes sin tipeo tienden a sentirse más cómodos con la soltura de JSON, mientras que los desarrolladores de lenguajes fuertemente tipados prefieren XML.

http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide