WSDL vs REST Pros y Contras

Los dos protocolos tienen usos muy diferentes en el mundo real.

SOAP(usando WSDL) es un estándar XML de gran peso que se centra en el paso de documentos. La ventaja de esto es que sus solicitudes y respuestas pueden estar muy bien estructuradas, e incluso pueden usar una DTD. La desventaja es que es XML, y es muy detallado. Sin embargo, esto es bueno si dos partes necesitan tener un contrato estricto(por ejemplo, para la comunicación interbancaria). SOAP también te permite crear capas de cosas como WS-Security en tu documento. SOAP es generalmente independiente del transporte, lo que significa que no necesariamente necesita usar HTTP.

REST es muy ligero, y se basa en el estándar HTTP para hacer su trabajo. Es genial tener un servicio web útil en funcionamiento rápidamente. Si usted no necesita un estricto Definición de API, este es el camino a seguir. La mayoría de los servicios web entran en esta categoría. Puede versionar su API para que las actualizaciones de la API no la rompan para las personas que usan versiones antiguas(siempre y cuando especifiquen una versión). REST esencialmente requiere HTTP, y es independiente del formato (lo que significa que puede usar XML, JSON, HTML, lo que sea).

Generalmente uso REST, porque no necesito características WS-* sofisticadas. SOAP es bueno si quieres que las computadoras entiendan tu servicio web usando un WSDL. Las especificaciones REST generalmente son solo legibles por humanos.

Respecto a WSDL (que significa "JABÓN") como "peso pesado". ¿Asuntos pesados cómo? Si el conjunto de herramientas está haciendo todo el "trabajo pesado" para usted, entonces ¿por qué importa?

Todavía no he necesitado consumir una API REST complicada. Cuando lo haga, espero que desee un WSDL, que mis herramientas convertirán con gusto en un conjunto de clases proxy, por lo que puedo llamar a lo que parecen ser métodos. En cambio, sospecho que para consumir una API basada en REST no trivial, será necesario escribir a mano una cantidad sustancial de código "ligero".

Incluso cuando todo haya terminado, todavía habrá traducido la documentación legible por humanos en código, con todo el riesgo asociado de que los humanos la lean mal. Dado que WSDL es una descripción legible por máquina del servicio, es mucho más difícil "leerlo mal".

Solo una nota: desde este post, he tenido la oportunidad de trabajar con un servicio REST moderadamente complicado. Yo, de hecho, deseo un WSDL o el equivalente, y, de hecho, tuve que escribir mucho código a mano. De hecho, una parte sustancial del tiempo de desarrollo se dedicó a eliminar la duplicación de código de todo el código que llamaba a diferentes operaciones de servicio "a mano".

Esto probablemente realmente pertenece como comentarios en varios de los mensajes anteriores, pero todavía no tengo el representante para hacer eso, así que aquí va.

Creo que es interesante que muchos de los pros y los contras a menudo citados para SOAP y REST tienen (IMO) muy poco que ver con los valores o límites reales de las dos tecnologías. Probablemente el pro más citado para el RESTO es que es "ligero" o tiende a ser más "legible por humanos". En un nivel esto es ciertamente cierto, RESTO tiene una barrera más baja a entrada - hay menos estructura requerida que el JABÓN (aunque estoy de acuerdo con aquellos que han dicho que las buenas herramientas son en gran parte la respuesta aquí - lástima que gran parte de las herramientas de JABÓN es bastante terrible).

Más allá de ese costo de entrada inicial, sin embargo, creo que la impresión REST proviene de una combinación de la forma de las URL de solicitud y la complejidad de los datos intercambiados por la mayoría de los servicios REST. REST tiende a fomentar URLs de solicitud más simples y más legibles por humanos y los datos tienden a ser más digerible también. Sin embargo, en qué medida son inherentes al RESTO y en qué medida son meramente accidentales. La estructura de URL más simple es un resultado directo de la arquitectura, pero podría aplicarse igualmente bien a los servicios basados en SOAP. Es más probable que los datos más digeribles sean el resultado de la falta de una estructura definida. Esto significa que es mejor que mantenga sus formatos de datos simples o que va a estar en un montón de trabajo. Así que aquí la estructura adicional del JABÓN, que debe ser un el beneficio es realmente permitir un diseño descuidado y ese diseño descuidado luego se usa como una excavación contra la tecnología.

Así que para su uso en el intercambio de datos estructurados entre sistemas informáticos No estoy seguro de que REST sea inherentemente mejor que SOAP (o viceversa), simplemente son diferentes. Creo que la comparación anterior de REST vs SOAP a dynamic vs. static typing es buena. Donde los lenguajes diánmicos tienden a tener problemas es en el mantenimiento y mantenimiento a largo plazo de un sistema (y por mucho tiempo término No estoy hablando de un año o 2, estoy hablando de 5 o 10). Será interesante ver si REST se encuentra con los mismos desafíos a lo largo del tiempo. Tiendo a pensar que lo hará, así que si estuviera construyendo un sistema de procesamiento de información distribuido, gravitaría hacia el SOAP como mecanismo de comunicación (también debido a la superposición y flexibilidad del protocolo de transferencia y aplicación que ofrece, como se ha mencionado anteriormente).

En otros lugares, aunque el DESCANSO parece más apropiado. AJAX entre el el cliente y su servidor (independientemente de la carga útil) es un ejemplo importante. No tengo mucho cuidado por la longevidad de este tipo de conexión y la facilidad de uso y la flexibilidad están en un premimum. Del mismo modo, si necesitaba un acceso rápido a algún servicio externo y no pensé que me iba a importar el mantenimiento de la interacción con el tiempo (de nuevo asumo que aquí es donde REST va a terminar costándome más, de una manera u otra), entonces podría elegir REST solo para poder entrar y salir pronto.

De todos modos, ambas son tecnologías viables y dependiendo de lo que se quiera hacer para una aplicación determinada, pueden servirle bien (o mal).

REST no es un protocolo; es un estilo arquitectónico. O un paradigma, si quieres. Eso significa que es mucho más flexible definido que el JABÓN es. Para CRUD básico, puede apoyarse en protocolos estándar como Atompub, pero para la mayoría de los servicios tendrá más comandos que solo eso.

Como consumidor, SOAP puede ser una bendición o una maldición, dependiendo del soporte del idioma. Puesto que SOAP está modelado en gran medida en un sistema estrictamente tipado, funciona mejor con lenguajes estáticamente tipeados. Para una dinámica lenguaje puede llegar a ser fácilmente crufty y superfluo. Además, el soporte de la biblioteca cliente no es tan bueno fuera del mundo de Java y. NET

Para mí debemos tener cuidado cuando usamos la palabra web service. Debemos especificar todo el tiempo si estamos hablando de servicio web SOAP, servicio web REST u otro tipo de servicios web porque estamos hablando de diferentes cosas aquí y la gente ya no entiende si nombramos todos ellos servicios web.

Básicamente los servicios web SOAP están muy bien establecidos desde hace años y siguen una especificación estricta que describe cómo comunicarse con ellos basándose en el SOAP especificación. Ahora los servicios web REST son un poco más nuevos y básicamente parecen más simples porque no están utilizando ningún protocolo de comunicación. Básicamente lo que envías y recibes cuando usas un servicio web REST es XML simple. A la gente le gusta porque pueden analizar el xml de la manera que quieran sin tener que lidiar con un protocolo de comunicación más sofisticado como SOAP.

Para mí los servicios REST son casi como si crearas un servlet en lugar de un servicio web SOAP. El servlet get data entrada y devolución de datos. El formato de los datos se basa en xml. También podemos imaginar usar algo más que xml si queremos. Por ejemplo, se podrían usar etiquetas en lugar de xml y eso ya no sería REST sino algo más (podría ser aún más liviano en términos de peso porque xml no es liviano por naturaleza). ¿Llamaríamos a eso todavía un servicio web? Sí, podríamos, pero eso no seguirá ningún estándar actual y este es el problema principal aquí si empezamos a llamar a todos los servicios web, pero podemos hacerlo la forma en que queremos entonces estamos perdiendo en el lado de la interoperabilidad de las cosas. Esto significa que el formato de los datos que se intercambian con el servicio web ya no está estandarizado. Eso requiere entonces que el servidor y el cliente acuerden el formato de los datos, mientras que con SOAP todo esto ya está predefinido y el servidor y el cliente pueden interoperar sin conocerse porque siguen el mismo estándar.

Lo que a la gente no le gusta con el JABÓN es que tienen dificultades para entiéndelo y no pueden generar las consultas manualmente. Sin embargo, las computadoras pueden hacer eso muy bien, por lo que aquí es donde debemos ser claros: ¿se supone que las consultas y respuestas de los servicios web deben ser utilizadas directamente por los usuarios finales o estamos de acuerdo en que los servicios web están debajo de la API llamada por los sistemas informáticos basados en algunos estándares normalizados?

SOAP: También se puede transportar a través de SMTP, lo que significa que también podemos invocar el servicio utilizando el formato de texto simple de correo electrónico

Necesita un framework/motor adicional que debe estar en la máquina de consumo del servicio web para convertir el mensaje SOAP a la estructura de los objetos respectivos en varios idiomas.

REST: Ahora WSDL2.0 soporta describir el servicio web REST también

Podemos usarlo cuando desee hacer que su servicio sea liviano, por ejemplo, llamando desde dispositivos móviles como cell teléfono, pda, etc...

Para sistemas empresariales en los que su sistema está confinado dentro de sus corporaciones, es más fácil y adecuado usar soap porque casi tiene el control de los clientes. es más fácil ya que hay una variedad de herramientas que crea clases (proxies) y parece que está haciendo su OOP regular que coincide con su entorno java o.net (en el que la mayoría de las empresas utilizan).

Usaría REST para aplicaciones orientadas a Internet para exponer interfaces (como la api de twitter) ya que los clientes pueden usar javascript o html u otros en los que escribir no es estricto. DESCANSAR siendo más liberal tiene más sentido.

También para clientes orientados a Internet (world wide web), es más fácil analizar json o xml saliendo de una interfaz rest en lugar de un xml puramente proveniente de una interfaz soap. es difícil usar proxies en javascript y javascript no soporta objetos de forma natural. Si está utilizando REST con javascript, normalmente analizará la cadena json y estará desactivado. frente a Internet las interfaces suelen ser muy simples (por lo que la mayoría de las veces su análisis simple) y no suele exigir consistencia por lo que REST es lo suficientemente adecuado.

Para aplicaciones empresariales no creo que REST sea adecuado porque las transacciones, la seguridad, la escritura estricta, los esquemas juegan un papel muy importante en el desarrollo de aplicaciones empresariales, por eso SOAP es más adecuado para ellos.

Mi conclusión es que SOAP es para sistemas empresariales, REST es para Internet o WWW. Puedes usarlo indistintamente, pero usted puede encontrarse teniendo un tiempo difícil con el tiempo no utilizar la herramienta correcta para el trabajo.

En defensa de REST sigue de cerca los principios de HTTP y direccionabilidad, por ejemplo, operaciones de lectura usan GET, operaciones de actualización usan POST, etc. Creo que este es un enfoque mucho más limpio. El libro de Oreilly RESTful Web Services explica esto mucho mejor que yo, si lo lee creo que preferiría el enfoque REST

El conjunto de herramientas en el lado del cliente sería uno. Y la familiaridad con el JABÓN sirve al otro. Más y más servicios están yendo por la ruta RESTful en estos días, y las pruebas de tales servicios se pueden hacer con ejemplos simples de cURL. Aunque, no es tan difícil implementar ambos métodos y permitir la utilización más amplia de los clientes.

Si necesitas elegir uno, te sugiero que DESCANSES, es más fácil.

Las respuestas anteriores contienen mucha información, pero creo que hay una diferencia filosófica que no se ha señalado. SOAP fue la respuesta a "¿cómo crear un sucesor moderno, orientado a objetos, independiente de la plataforma y el protocolo de RPC?". REST se desarrolló a partir de la pregunta: "¿cómo tomar las ideas que hicieron que HTTP fuera tan exitoso para la web y usarlas para la computación distribuida?"

SOAP se trata de darle herramientas para hacer que la programación distribuida se vea como ... programación. REST intenta imponer un estilo para simplificar las interfaces distribuidas, de modo que los recursos distribuidos puedan referirse entre sí como las páginas html distribuidas pueden referirse entre sí. Una forma de hacerlo es intentar (principalmente) restringir las operaciones a "CRUD" en los recursos (crear, leer, actualizar, eliminar).

REST es todavía joven although aunque está orientado hacia servicios "legibles por humanos", no descarta servicios de introspección, etc. o creación automática de proxies. Sin embargo, estos no han sido estandarizados (como escribo). SOAP te da estas cosas, pero (EN mi Humilde opinión) te da "solo" estas cosas, mientras que el estilo impuesto por REST ya está alentando la difusión de los servicios web debido a su simplicidad. Yo mismo animaría a los proveedores de servicios novatos a elegir REST a menos que haya características específicas proporcionadas por SOAP que necesiten usar.

En mi opinión, entonces, si está implementando una API "greenfield" y no sabe mucho sobre posibles clientes, elegiría DESCANSE ya que el estilo que fomenta tiende a ayudar a que las interfaces sean comprensibles y fáciles de desarrollar. Si sabes mucho sobre cliente y servidor, y hay herramientas de SOAP específicas que harán la vida fácil para ambos, entonces no sería religioso sobre el DESCANSO, sin embargo.

Puede cambiar fácilmente sus componentes web WCF WSDL-spewing a otros usos simplemente cambiando los ajustes de configuración. Puede ir a través de HTTP y luego también tuberías con nombre, tcp, protocolos personalizados, etc. sin tener que cambiar su código. Creo que los componentes de WCF también pueden ser más fáciles de configurar para cosas como seguridad, llamadas bidireccionales, transacciones, concurrencia, etc.

REST prácticamente lo limita a HTTP (lo cual está bien en muchos casos).

Sé que esta discusión es antigua, pero después de leer todas las respuestas y comentadas, creo que todos se perdieron el punto más importante sobre la diferencia entre los 2 sistemas: SOAP utiliza tipos complejos no solo para darle los datos, sino para validarlos y mantenerlos en la estricta designación de tipo para la que se definió. Un WSDL le dice cuál es el formato de datos, cuál es el tipo de datos, le permite agregar reglas de estilo de patrón reg-ex y define cuántas veces debe ser, y puede ser, permitido en una solicitud / respuesta. El resto, por otro lado, no tiene ninguno de estos mecanismos.

SOAP es complejo y pesado porque le permite enviar datos jerárquicos pesados complejos. REST es texto sin formato, con el origen y el punto final ordenando las reglas.

SOAP es independiente del negocio, porque tiene todas las reglas de datos incrustadas en el documento.

La diferencia entre SOAP y REST es que SOAP es un esquema orientado al negocio autónomo. REST es un texto documento.