Was ist die heutige Bedeutung von SOAP?

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?

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

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.

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.