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?
@ Gilbert - die Frage erwähnt das schon als Inspiration . Meiner Meinung nach ist dies eher philosophisch als praktisch. Was zur Erfindung führte, anstatt welche, sollte ich wählen.
SDG
2
Den Abwasch machen? <G>
Loren Pechtel
2
Ein Berater nutzte irgendwo ein Unternehmensinformationssystem, das schnell und reaktionsschnell war. Da die Einnahmen verdampften, erfanden sie einen Standard mit brutal langsamem Overhead, der dem Management empfohlen werden sollte. Es hat XMLs, sagten sie! XMLs sind gut und unternehmerisch! Die ständigen Entwickler waren machtlos zu widerstehen. Jetzt hat der Berater eine endlose Einnahmequelle, die die Leistung des gletscherartigen ESB verbessert, und die Welt hat wieder Recht.
Affe
Antworten:
8
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 :-)
Viele RESTful-Sachen wurden definitiv verwendet, bevor SOAP erfunden wurde. Sie nannten es im Großen und Ganzen GET und POST.
Wyatt Barnett
4
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.
FinnNK: Immer noch nicht überzeugt ... Sicher, Sie können alles zu einem GET oder PUT machen, aber ich bin mir nicht sicher, ob es in jedem Fall sehr REST ist. Stellen Sie sich beispielsweise einen Webservice vor, der eine Liste von Datensätzen empfängt, diese mit vorhandenen Datensätzen in der Datenbank zusammenführt (neue Datensätze einfügt und vorhandene Datensätze aktualisiert, aber nichts löscht) und eine Liste aller Datensätze zurückgibt, die nicht aktuell waren. Wie macht man das RESTfull?
user281377
REST-Ressourcen können Ressourcen genauso verarbeiten wie Substantivressourcen. Hier würden Sie einen Endpunkt verfügbar machen, der das Update akzeptiert, sowie eine Art ID. Anschließend können Sie mit dieser ID abfragen, um die nicht aktuellen Datensätze abzurufen (und der Abfrageort selbst kann möglicherweise über einen Link ermittelt werden). Das besagte Batch-Update ist eines der klassischen Szenarien für SOAP. Verwenden Sie das, was am besten zu mir passt.
FinnNk
@ammoQ: Eine Möglichkeit, Ihren Dienst wahrscheinlich mit einem POST der Liste der Datensätze zu erledigen. Bei der Rücksendung können Sie unter anderem eine URL zu GET angeben, in der die veralteten Datensätze aufgeführt sind.
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. . .
+1. Ihre Antwort war die einzige, die SOAP mit seinem Ursprung verbindet - verteiltes Computing. Bei SOAP ging es nicht so sehr um HTTP, sondern um das Gespräch von Anwendung zu Anwendung - wo Bestien wie CORBA versagten!
Dipan Mehta
2
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.
Antworten:
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 :-)
quelle
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.
quelle
Aus Wikipedia :
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.
quelle
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. . .
quelle
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.
quelle
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.
quelle