¿Por qué usar SOAP para servicios web?

Question

He leído un tutorial "web-service-php-mysql-xml-json".

Parece que todo está bien. Pero entonces, ¿por qué deberíamos usar jabón para servicios web?

Answer 1

Cuando la construcción de servicios web se puede ir en dos direcciones:

• de SOAP
• RESTO

La mayoría de la gente elige el camino de la menor resistencia, que es RESTO. Esto significa simplicidad, facilidad de desarrollo, a través de HTTP de la manera en que está destinado a ser utilizado, hacer buen uso de servidores proxy caché, resultados legibles más humanos, etc.

de SOAP en el otro extremo es más pesado que el descanso y también es respaldado por un gran conjunto de specifications. Pero porque es más complejo (SOAP solía ser el acrónimo de Simple Object Access Protocol, que resultó ser ... NO) SOAP no es del agrado de mucha gente.

Ambos enfoques funcionan y ambos tienen ventajas y desventajas.

Por ejemplo, SOAP puede utilizar cualquier protocolo de transporte no solo HTTP (S), SOAP ofrece más opciones cuando se trata de seguridad, SOAP ofrece mensajería confiable, etc. REST, por otro lado, permite muchos tipos diferentes de datos formatos, REST permite una mejor compatibilidad para los navegadores debido al formato JSON, REST tiene un mejor rendimiento, etc. etc.

No voy a entrar en más detalles ya que puede encontrar muchas comparaciones SOAP vs REST en la web . Lo que quiero enfatizar es el hecho de que en algunos casos uno funciona mejor que el otro y depende de usted determinar y elegir cuál implementar dado su caso particular.

EDIT: Para responder a su pregunta:

¿por qué utilizar SOAP o REST? podemos tener servicio web sin ellos?

Bueno, el W3C define un servicio web como "a software system designed to support interoperable machine-to-machine interaction over a network".

OK ... eso es bueno para una definición. Pero esta no es la definición de SOAP/REST, este requisito se puede lanzar con éxito en un communication protocol para manejar.

Así que, básicamente, podría tener un servicio web utilizando cualquier protocolo de comunicación que desee (incluso creando el suyo propio) siempre que sea compatible con la "interacción interoperable de máquina a máquina". Esto también significa algo más que SOAP o REST (OK ... REST no es un protocolo, solo lo uso aquí como referencia para probar mi punto ... tan desnudo conmigo).

Pero usted crea un servicio web porque desea que algunos clientes utilicen su servicio. Y sus clientes están en el salvaje oeste salvaje (es decir, la web: D) y la gente habla SOAP/REST. Y ahí vienes y dices: "No nos gusta SOAP y REST aquí en nuestra tienda, nos gustan cosas como RPC, CORBA y nuestra propia creación única, el protocolo" Bone Crusher 10000 ".Si usted quiere hacer negocios con nosotros, usted va a aprender el "Bone Crusher 10000"". Y sus clientes van a decir (ceja levantada) "Yeaaaaah righttttt .....".

(I' Suponiendo aquí que su protocolo no será algo que se sacudirá en el suelo que superará totalmente al SOAP/REST: D)

Por lo tanto, si no usa SOAP/REST limitará su audiencia objetivo. Es como el inglés ejemplo. No soy un hablante nativo de inglés, ¿verdad? Bueno, en realidad no importa ya que somos capaces de comunicarnos en inglés. ¿Quieres probar esto en Icelandic? ¿Me esperarás mientras aprendo Icelandic, porque eso es no mi nativ ¿e idioma?

Como ya he dicho, Depende de usted para determinar y elegir lo que para poner en práctica dado el caso particular, pero si uno se aleja de la tecnología conocida Pilas de deshacerse de lo que viene con eso: mucha experiencia, recursos, herramientas y opciones de comunicación.

Como ejemplo cerrando, hay una gran cantidad de apoyo para el protocolo SOAP hoy y se puede generar clientes muy fácilmente a partir del archivo WSDL. Y presto ... sus clientes pueden comunicarse con su servicio web. ¿Va a ser tan fácil como esto con "Bone Crusher 10000"? Si escribe las herramientas, proporcione los recursos, soporte, etc. ¡Sí! Pero eso le costará tiempo y dinero para crear algo que ya se inventó y está en uso hoy en día.

Answer 2

Un punto importante que el usuario159088 menciona en su respuesta es "[...] puede generar clientes muy fácilmente a partir del archivo WSDL [...]"!

Me gustaría dar más detalles sobre esto:

Usted puede utilizar el jabón en conjunción con WSDL que se estandarizaron lo que significa que las personas que conocen la norma (WSDL) pueden aprender de él lo que las operaciones de un servicio web y ofertas cómo se intercambian los datos.

Este conocimiento puede ser utilizado F. E. para crear herramientas que generan clases/objetos de enlazador seguro del archivo WSDL. Puede hacer uso de esas clases generadas (para hacer RPC) sin implementar manualmente las solicitudes y la codificación/análisis de los datos que se intercambian.

Mientras que para REST no existe un estándar (como un esquema WSDL) sobre el aspecto de los datos intercambiados. Como resultado, a menudo terminas analizando los datos por tu cuenta.

---

Un segundo punto es que REST trabaja principalmente con el protocolo HTTP (s) (que se basa en él). Utiliza los verbos CRUD (CREAR/LEER/ACTUALIZAR/ELIMINAR) del protocolo HTTP (s). SOAP no confía en él y, por lo tanto, puede utilizarse con otros protocolos, como.