Was ist die heutige Bedeutung von SOAP?


51

Das letzte Mal, dass ich auf einen SOAP-basierten Service gestoßen bin, war während meines Praktikums in einer Finanzfirma im Jahr 2013. Damals habe ich meine Karriere in der IT begonnen. Ich erinnere mich, dass ich in einem meiner Ingenieurkurse etwas Lernmaterial über SOAP hatte. Abgesehen davon habe ich SOAP während meiner Karriere nicht viel benutzt.

Dies stelle ich, da in einem meiner letzten Interviews die Frage nach dem Unterschied zwischen SOAP und REST gestellt wurde. Soweit ich weiß (und was ich bei Google gefunden habe), ist SOAP ein Protokoll mit enger Kopplung zwischen Client und Server für den Informationsaustausch, das eng mit der Geschäftslogik verbunden ist. Während REST eine flexiblere zustandslose Architektur für die Datenübertragung ist.

Kann mich jemand bitte korrigieren, wenn ich mich in diesem Unterschied zwischen SOAP und REST irre? Welche Bedeutung hat SOAP heute? Entwickeln die Leute immer noch neue SOAP-basierte APIs oder handelt es sich derzeit hauptsächlich um ein Vermächtnis?




14
@gnat: Für das, was es wert ist, sind die Antworten in diesen beiden Fragen alle schrecklich.
Robert Harvey

7
Haben Sie jemals einen REST-Service gesehen? Ich sehe nur "Webdienste, die endlich gelernt haben, was HTTP-Verben bedeuten". Warum rufen wir plötzlich HTTP REST auf?
Luaan

8
@Luaan: Es ist nichts Plötzliches dabei; Menschen haben den Begriff "REST" seit Jahren missbraucht.
Leichtigkeit Rennen mit Monica

Antworten:


58

REST ist in der Tat ein architektonischer Stil. SOAP ist ein Datenprotokoll. Die Unterscheidung ist wichtig; Sie können sie nicht direkt vergleichen.

Der Hauptzweck von REST besteht darin , Ressourcen im Internet darzustellen und Mechanismen zu ihrer Entdeckung bereitzustellen. Im Gegensatz dazu wird SOAP für die Kommunikation strukturierter Daten zwischen Computern verwendet, und das ist alles, was es wirklich tut.

Beachten Sie, dass Sie REST nicht wirklich benötigen, um eine Client / Server-Beziehung zwischen zwei Computern im Internet herzustellen. Alles, was Sie brauchen, ist ein Mechanismus, der JSON oder XML überträgt, und das brauchen Sie nicht einmal, wenn Sie bereit sind, mit allen anderen inkompatibel zu sein.

Trotzdem ist SOAP für neue, öffentlich zugängliche APIs in Ungnade gefallen, obwohl es immer noch häufig für B2B-Anwendungen verwendet wird, da Sie damit einen "Datenvertrag" definieren können. JSON-Webdienste haben den Vorteil, dass sie relativ leicht und flexibel sind. Da Javascript JSON von Haus aus erkennt, ist dies eine natürliche Wahl für Browser.

Aber nichts davon hat wirklich viel mit REST zu tun.

Weiterführende Literatur
Ist REST besser als SOAP? (Guter Artikel, obwohl REST fälschlicherweise als Protokoll bezeichnet wird).
Das Richardson-Reifegradmodell


3
Ich würde sagen, die Killerfunktion von JSON-Webdiensten ist genau die Tatsache, dass Browser XML und SOAP nur unzureichend unterstützen, während sie JSON (fast) nativ unterstützen. SOAP hat einiges zu bieten, aber wenn Sie keine AJAX-Anforderungen für einen SOAP-Service stellen können, ist dieser nicht mehr verfügbar. Javascript / JSON wurde der kleinste gemeinsame Nenner des Internets, so dass Sie wäre ein großer Vorteil braucht es nicht zu benutzen, und SOAP ist nicht , dass viel besser.
Luaan

3
@Luaan Ich würde nicht sagen, dass Browser XML schlecht unterstützen. Tatsächlich gibt es kaum etwas Besseres, als eine XML- HttpRequest auszuführen und auf ein Attribut mit einem analysierten DOM zuzugreifen. Es ist nur so, dass, wenn man eine typische Datenstruktur und kein Dokument haben möchte, JSON einfach besser geeignet ist, egal ob Sie sich im Browser oder in einer anderen Umgebung befinden.
André Paramés

4
Alles, was Sie brauchen, ist ein Mechanismus, der JSON oder XML überträgt, und das brauchen Sie nicht einmal, wenn Sie bereit sind, mit allen anderen inkompatibel zu sein. -1: Wenn Sie einen Client und einen Server verbinden möchten, benötigen Sie nur ein beliebiges Protokoll, von dem beide Seiten wissen, dass es nichts mit der Verwendung von XML, JSON oder der Kompatibilität mit allen anderen zu tun hat. Selbst wenn Sie json oder xml verwenden, können Sie nicht garantieren, dass Sie mit jedem oder sogar mit jemandem kompatibel sind. Json und XML sind nur Datenformate, nichts weiter.
Paul Wasilewski

6
@ PaulWasilewski: Ja, das habe ich gesagt. Lass dich nicht auf Worte ein. Es gibt einen Grund, warum jeder JSON verwendet. Es ist ein Standard. Die Verwendung garantiert, dass Sie etwas verwenden, das für andere erkennbar ist.
Robert Harvey

3
@RobertHarvey, nein, es ist nicht das, was du geschrieben hast. Vielleicht hast du es so gemeint. JSON ist Standard, na und? CSV, Protcol Buffers, BSON ist ebenso standardisiert wie viele andere. Der Grund, warum alle JSON verwenden, ist vielfältig. Und es gibt sogar einige, die JSON verwenden, weil alle JSON verwenden;)
Paul Wasilewski

29

REST ist viel begrenzter als SOAP, was seine Stärke und den Grund für seine Beliebtheit darstellt.

In SOAP sind die zulässigen Vorgänge und Datentypen im Wesentlichen unbegrenzt. SOAP ist ein Remoteprozedurprotokoll, mit dem Sie lokale APIs im gesamten Netzwerk verfügbar machen können, ohne dabei die Wiedergabetreue zu verlieren. Dies machte SOAP in Unternehmensumgebungen beliebt, in denen komplexe Transaktionssysteme über das Netzwerk hinweg interagieren mussten, ohne dabei an Genauigkeit zu verlieren. Dieser Reichtum an Fähigkeiten ist auch der Nachteil von SOAP, da es so schwierig ist, SOAP-APIs zu verstehen und zu verwenden, dass automatisierte Tools in Form von WSDL- und SOAP-Clientbibliotheken erforderlich waren, um einen Sinn zu ergeben. Darüber hinaus ist es in öffentlich zugänglichen APIs unattraktiv, den vollen Funktionsumfang des zugrunde liegenden Systems freizugeben, wenn Sie Abstraktionen bereitstellen möchten, mit denen Sie das zugrunde liegende System weiterentwickeln können, ohne Ihre API unterbrechen oder versionieren zu müssen.

REST + JSON wurde vor allem wegen seiner Einfachheit immer beliebter. Es definiert eine begrenzte Anzahl von Vorgängen mit einer begrenzten Anzahl von Datentypen, sodass der API-Designer Abstraktionen sorgfältig entwerfen muss, die in dieses begrenzte Vokabular passen, und die Zuordnung der Geschäftsdomäne zu REST-Ressourcen wirklich durchdenken muss. Eine REST-API ist einfach zu verstehen und ohne spezielle Tools zu verwenden. Für eine öffentlich zugängliche API, bei der Ihre API-Benutzer möglicherweise über alle Fähigkeiten und Kenntnisse verfügen, ist dies genau das, was Sie möchten. Aus diesem Grund wurden alle APIs, die Sie im Internet sehen, auf REST umgestellt. SOAP ist auf Unternehmenssituationen beschränkt, in denen immer noch der Wunsch und die Notwendigkeit besteht, komplexe APIs zwischen Systemen gemeinsam zu nutzen. Jedoch,

Die Leute haben erkannt, dass die Einschränkungen, die Sie auf Ihr API-Design anwenden müssen, um die API so einfach und abstrakt zu gestalten, dass sie wartbar und benutzerfreundlich ist, genau die von REST eingeführten Einschränkungen sind, die SOAPs effektiv neutralisieren Vorteile, die Ihnen nur die Nachteile bereiten. Sie könnten eine vereinfachte API mit SOAP erstellen, diese wäre jedoch nie so einfach zu verwenden wie REST. In der Praxis wählt also jeder einfach REST.


4
Die gute alte Debatte zwischen statischer und dynamischer Typisierung, yay: D Ordentlich und hart vs. hackig und einfach, der Krieg, der niemals endet.
Luaan

@Luaan ... und dynamic gewinnt immer für den Datenaustausch. youtube.com/watch?v=ROor6_NGIWU
Jared Smith

6
@JaredSmith Ich bin nicht einverstanden. Verträge sollten eingehalten werden, damit beide Endpunkte die Daten korrekt abbilden. Wenn Sie dies durch Veröffentlichung von Metadaten anstelle von fehleranfälligen Dokumentationsseiten tun können, warum sollten Sie das nicht tun?
drake7707

1
Praktisches REST ist ein Protokoll; These und Religion sind "Baustil". Diese Antwort vergleicht die praktische Ruhe mit der praktischen Seife.
Bmargulies

1
Ihre Antwort hat bereits gezeigt, dass Sie REST nicht verstehen, und Sie kommentieren dies.
Paul Wasilewski

5

Sie können REST und SOAP nicht vergleichen. REST ist ein Architekturstil, während SOAP ein Protokoll ist.

Leider wurde REST umgangssprachlich als Synonym für RESTful HTTP Service gesprochen, was eine Realisierung einer REST-gestalteten Architektur mit HTTP als (Applikations-) Protokoll bedeutet.

REST basiert auf folgenden Prinzipien (Einschränkungen und Elementen) (in Klammern die Realisierung in RESTful HTTP) [1] .

  • Zustandslos (HTTP ist ein zustandsloses Protokoll)
  • Ressource (identifiziert durch URIs)
  • Einheitliche Schnittstelle (HTTP-Methoden)
  • Darstellung (MIME-TYPE)
  • HATEOS (Hyperlinks)
  • Cache (HTTP-Cache)

Andererseits meinen viele Leute mit SOAP einen auf WSDL und SOAP basierenden Webservice, der Teil der W3C-Webservice-Architektur ist [2] .

  • SOAP wird als Protokoll zum Informationsaustausch verwendet (im Grunde genommen Methodenname, Parameter, Rückgabewerte, Datentypen, ...).
  • WSDL ist eine Schnittstellendefinitionssprache zur Beschreibung des Webdienstes.

Was ist die heutige Bedeutung von SOAP *?

SOAP ist ein W3C-Standard und wird als Informationsaustauschformat in W3C-Webdiensten verwendet. Diese Webservices wurden - insbesondere während des Hype um SOAs (serviceorientierte Architekturen) um 2008 (+ - 3 Jahre) - und sind (leider) immer noch hauptsächlich in Unternehmensanwendungen implementiert.

Dies hat mehrere Gründe. RESTful HTTP war damals nicht bekannt und wurde missverstanden. Leider ist es immer noch falsch verstanden, werfen Sie einen Blick auf die anderen Antworten

„[...] REST ist viel begrenzter als SOAP [...].“

„Der Hauptzweck von REST ist die Darstellung von Ressourcen im Internet [...].“

Darüber hinaus sind SOAP (und WSDL) Teil des W3C-Webdienst-Protokollstapels, der noch mehr Standards für die Implementierung eines Webdienstes bietet.

Entwickeln die Leute immer noch neue SOAP-basierte APIs oder handelt es sich derzeit hauptsächlich um ein Vermächtnis?

Also ja, es gibt noch und es wird auch in Zukunft Systeme geben, die SOAP verwenden (zumindest in Unternehmenssystemen, meistens hinter den Türen). Aber die Mehrheit versucht heutzutage, eine Art "REST" zu machen.

Kann mich jemand bitte korrigieren, wenn ich mich in diesem Unterschied zwischen SOAP und REST irre?

Die Aussage, dass REST eine flexiblere zustandslose Architektur für die Datenübertragung ist, ist keine gute Erklärung. Einfach gesagt ist REST ein Architekturstil mit spezifischen Einschränkungen und Elementen. Während SOAP ein Informationsaustauschprotokoll ist.

Wie ich schon schrieb, kann man sie nicht vergleichen. Sie können jedoch einen RESTful HTTP-Webdienst mit einem SOAP / WSDL-Webdienst vergleichen.


"Sie können jedoch einen RESTful HTTP-Webdienst mit einem SOAP / WSDL-Webdienst vergleichen." Aber darum bittet das OP. Hat das schon jemand beantwortet?
RoboJ1M
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.