Wofür wurde SOAP erfunden?

Diese Frage ist von dieser inspiriert . Was war das ursprüngliche Ziel der Erfindung von SOAP? Warum wurde es erfunden, als wir HTTP und REST der alten Art hatten?

REST ist kein Standard, sondern eine (lose definierte) Architektur. Und es ist an HTTP gebunden, was viele Menschen in der Unternehmenswelt als Einschränkung betrachteten. Sie dachten also, sie brauchten einen allgemeinen Standard, der auch über andere Transferschichten funktioniert.

Und übrigens wurde SOAP vor REST definiert (zumindest laut Wikipedia :-)

SOAP ist für den Austausch komplexer Datenstrukturen weitaus besser geeignet als einfaches HTTP. REST ist praktisch praktisch auf CRUD-Operationen beschränkt, während SOAP beliebige Methodenaufrufe zulässt, die möglicherweise nicht in das REST-Schema übernommen werden können.

Aus Wikipedia :

SOAP, ursprünglich als Simple Object Access Protocol definiert, ist eine Protokollspezifikation für den Austausch strukturierter Informationen bei der Implementierung von Webdiensten in Computernetzwerken. ... SOAP weist drei Hauptmerkmale auf: Erweiterbarkeit (Sicherheit und WS-Routing gehören zu den in der Entwicklung befindlichen Erweiterungen), Neutralität (SOAP kann über jedes Transportprotokoll wie HTTP, SMTP oder sogar TCP verwendet werden) und Unabhängigkeit (SOAP ermöglicht dies) jedes Programmiermodell).

SOAP ist nicht auf HTTP beschränkt und bietet sofort Sicherheit.

Wenn Sie HTTP verwenden und keine Sicherheit benötigen (Ihr Webdienst ist öffentlich zugänglich), benötigen Sie kein SOAP.

Ich war nicht im Raum, aber ich würde allgemein sagen, dass SOAP eine sehr, sehr gute Idee und eine sehr vernünftige Antwort auf die anderen RPC-Optionen war, die Mitte bis Ende der 90er Jahre existierten. Wie CORBA , ein Tier, mit dem ich nicht persönlich zu tun hatte, dessen bloße Erwähnung erwachsene Männer dazu bringen kann, sich selbst zu beschmutzen. Optionen jenseits von CORBA waren in vielen Fällen tatsächlich beängstigender und es gab wenig Standardisierung und viele benutzerdefinierte Messaging-Protokolle. Integrierte Systeme waren sehr, sehr schwierige Dinge. Es gab gute Gründe, sich nicht auf HTTP als Transportmittel zu verlassen. In den späten 90ern betrugen typische LAN-Geschwindigkeiten 10 Megabit oder weniger, WAN-Geschwindigkeiten wurden häufig in Baud gemessen. Die gesamte Edge-Caching-Infrastruktur, die so viel für REST leistet, war nicht vorhanden.

Das bringt uns zu SOAP - das an und für sich kein Transportmedium spezifiziert. Ich glaube, jemand hat es geschafft, einen SOAP-Anruf über Brieftaube zu implementieren. Oder vielleicht eine afrikanische Schwalbe. In jedem Fall ist die Implementierung der Messaging-Option wesentlich einfacher als zuvor. Und wenn Sie ein anständiges SOAP-Toolkit hatten, war es viel, viel einfacher zu konsumieren als alles andere, was vorher gekommen war. Und einfacher, Werkzeuge für zu machen. So einfach, dass sie dachten, sie müssten das Protokoll erweitern. Und hier kommt WS- * ins Spiel. Dort sind die Räder von diesem LKW gefallen. . .

SOAP ist ein Messaging-Protokoll, das aus demselben Grund erstellt wurde, aus dem auch jedes andere Messaging-Protokoll erstellt wurde. um die Art und Weise zu standardisieren, in der Objektinformationen weitergegeben werden. Wie auf der Wikipedia- Seite angegeben, stammt es von Microsoft und ist jetzt ein offener Standard, der vom W3C gepflegt wird.

Die bessere Frage ist, warum Sie zwischen SOAP oder einem Schema mit XML-Geschmack oder JSON oder was auch immer wählen sollten, und die Antwort lautet, was in Ihrer speziellen Situation am einfachsten / praktischsten ist.

Meiner Meinung nach ist SOAP eine weitere Einstellung bei RPC . Schauen Sie sich an, wie Sie WebService heutzutage verfügbar machen. Eine Partei markiert die Methode als WebService und die andere ruft nur WSDL ab und verwendet Remote-Methoden, als wären sie lokal. Ich bin mir aller SOAP-Probleme ziemlich bewusst, aber auf einer gewissen Abstraktionsebene hält SOAP / WS sein RPC-Versprechen ein. Natürlich können Sie eine API entwickeln, die auf der REST-Architektur basiert, aber es wird immer noch erforderlich sein, dass andere Parteien einige Bits codieren, die sich irgendwie der RPC-Definition widersetzen.