¿Para qué se inventó SOAP?

Esta pregunta está inspirada en esta . ¿Cuál fue el objetivo inicial de inventar SOAP? ¿Por qué se inventó cuando teníamos HTTP y REST antiguos?

REST no es un estándar, es una arquitectura (poco definida). Y está vinculado a HTTP, que mucha gente en el mundo corporativo vio como una limitación. Por lo tanto, pensaron que necesitaban un estándar general adecuado, que también funciona sobre otras capas de transferencia.

Y por cierto SOAP se definió antes de REST (al menos según Wikipedia :-)

SOAP es mucho más adecuado que HTTP simple para intercambiar estructuras de datos complejas. REST está, por diseño, prácticamente restringido a operaciones CRUD, mientras que SOAP permite llamadas a métodos arbitrarios, que pueden ser algo que no se puede presionar en el esquema REST.

De Wikipedia :

SOAP, originalmente definido como Protocolo simple de acceso a objetos, es una especificación de protocolo para intercambiar información estructurada en la implementación de servicios web en redes informáticas. ... SOAP tiene tres características principales: Extensibilidad (la seguridad y el enrutamiento WS se encuentran entre las extensiones en desarrollo), Neutralidad (SOAP puede usarse sobre cualquier protocolo de transporte como HTTP, SMTP o incluso TCP) e Independencia (SOAP permite cualquier modelo de programación).

SOAP no está limitado a HTTP y proporciona seguridad desde el primer momento.

Si está utilizando HTTP y no necesita seguridad (su servicio web está abierto al público), entonces no necesita SOAP.

No estaba en la sala, pero generalmente diría que SOAP fue una muy, muy buena idea y una respuesta muy razonable a las otras opciones de RPC que existían a mediados y finales de los 90. Como CORBA , una bestia con la que no puedo decir que haya tenido que lidiar personalmente, pero la mera mención de eso puede hacer que los hombres adultos se contaminen. Las opciones más allá de CORBA en realidad eran más aterradoras en muchos casos y había poca estandarización y muchos protocolos de mensajería personalizados. Los sistemas integrados eran cosas muy, muy difíciles. Había buenas razones para no confiar en HTTP como transporte. A finales de los 90, las velocidades típicas de LAN eran de 10 megabits o menos, las velocidades de WAN a menudo se midieron en baudios. No existía toda la infraestructura de almacenamiento en caché de borde que hace tanto por REST.

Lo que nos lleva a SOAP, que en sí mismo no especifica un medio de transporte. Creo que alguien logró implementar una llamada SOAP sobre paloma mensajera. O tal vez una golondrina africana. En cualquier caso, es una opción de mensajería mucho más simple que la anterior. Y si tenía un kit de herramientas SOAP decente, era mucho, mucho más fácil de consumir que cualquier otra cosa que haya llegado antes. Y más fácil de hacer herramientas para. Tan fácil que pensaron que necesitaban extender el protocolo. Y ahí es donde entra WS- *. Que es donde las ruedas se cayeron de ese camión. . .

SOAP es un protocolo de mensajería, que se creó por la misma razón que se creó cualquier otro protocolo de mensajería; para estandarizar la forma en que se transmite la información del objeto. Como dice la página de Wikipedia , se originó en Microsoft, y ahora es un estándar abierto mantenido por el W3C.

La mejor pregunta es por qué elegir entre SOAP o algún esquema con sabor a XML o JSON o lo que sea, y la respuesta se reduce a usar lo que sea más fácil / práctico en su situación particular.

En mi opinión, SOAP es otra versión de RPC . Solo eche un vistazo a cómo expone WebService en estos días. Una de las partes marca el método como WebService y la otra solo busca WSDL y usa métodos remotos como si fueran locales. Soy bastante consciente de todos los problemas de SOAP, pero en algún nivel de abstracción SOAP / WS cumple con su promesa de RPC. Por supuesto, puede crear una API basada en la arquitectura REST, pero aún requerirá que otra parte codifique algunos bits que de alguna manera desafían la definición de RPC.