SOAP vs REST (Unterschiede)

Question

Ich habe Artikel über die Unterschiede zwischen SOAP und REST als Kommunikationsprotokoll für Webdienste gelesen, aber ich glaube, dass die größten Vorteile von REST gegenüber SOAP sind:

1. REST ist dynamischer, es ist nicht notwendig, UDDI (Universal Description, Discovery, and Integration) zu erstellen und zu aktualisieren.

2. REST ist nicht auf das XML-Format beschränkt. RESTful-Webdienste können Klartext/JSON/XML senden.

Aber SOAP ist standardisierter (z. B.: Sicherheit).

Also liege ich mit diesen Punkten richtig?

Answer 1

Zunächst einmal: Offiziell wäre die korrekte Frage Webdienste + WSDL + SOAP vs REST.

Denn, obwohl der Webdienst im weitesten Sinne verwendet wird, wenn das HTTP-Protokoll zur Übertragung von Daten anstelle von Webseiten verwendet wird, ist es offiziell eine sehr spezifische Form dieses Konzepts. Gemäß der Definition ist REST nicht "Webdienst".

In der Praxis ignoriert das jedoch jeder, also lasst uns das auch ignorieren

Es gibt bereits technische Antworten, also werde ich versuchen, etwas Intuition zu geben.

Angenommen, Sie möchten eine Funktion in einem entfernten Computer aufrufen, die in einer anderen Programmiersprache implementiert ist (dies wird oft als Remote Procedure Call/RPC bezeichnet). Nehmen wir an, dass die Funktion unter einer bestimmten URL zu finden ist, die von der Person bereitgestellt wird, die sie geschrieben hat. Sie müssen ihr eine Nachricht (auf irgendeine Weise) senden und eine Antwort erhalten. Es gibt also zwei Hauptfragen zu berücksichtigen.

• Wie lautet das Format der zu sendenden Nachricht?
• Wie sollte die Nachricht hin und her transportiert werden?

Für die erste Frage ist die offizielle Definition WSDL. Dies ist eine XML-Datei, die detailliert und streng das beschreibt, was die Parameter sind, was ihre Typen sind, Namen, Standardwerte, der Name der zu aufrufenden Funktion usw. Ein Beispiel für WSDL zeigt, dass die Datei menschenlesbar ist (aber nicht einfach).

Zu der zweiten Frage gibt es verschiedene Antworten. Die einzige, die jedoch in der Praxis verwendet wird, ist SOAP. Die Hauptidee besteht darin, das vorherige XML (die eigentliche Nachricht) in noch ein weiteres XML (das Codierungsinfos und andere hilfreiche Infos enthält) zu verpacken und über HTTP zu senden. Die POST-Methode des HTTP wird verwendet, um die Nachricht zu senden, da immer ein Body vorhanden ist.

Die Hauptidee dieses gesamten Ansatzes ist, dass Sie einer URL eine Funktion zuordnen, also eine Aktion. Wenn Sie also eine Liste von Kunden in einem Server haben und einen anzeigen/aktualisieren/löschen möchten, müssen Sie 3 URLs haben:

• meineapp/kunde-anzeigen und im Nachrichten-Body die ID des anzusehenden Kunden übergeben.
• meineapp/kunde-aktualisieren und im Body die ID des Kunden sowie die neuen Daten übergeben
• meineapp/kunde-löschen und die ID im Body

Der REST-Ansatz sieht die Dinge anders. Eine URL sollte keine Aktion, sondern eine Sache (im REST-Jargon Ressource genannt) repräsentieren. Da das HTTP-Protokoll (das wir bereits verwenden) Verben unterstützt, sollten diese Verben verwendet werden, um anzugeben, welche Aktionen auf der Sache durchzuführen sind.

Also würde bei der REST-Ansicht der Kunde Nummer 12 unter der URL meineapp/kunden/12 gefunden werden. Um die Kundendaten anzuzeigen, bringen Sie die URL mit einer GET-Anfrage aufrufen. Um sie zu löschen, dieselbe URL mit einem DELETE-Verb. Um sie zu aktualisieren, wieder dieselbe URL mit einem POST-Verb und den neuen Inhalt im Anfrage-Body.

Für weitere Details darüber, welche Anforderungen ein Dienst erfüllen muss, um wirklich als RESTful angesehen zu werden, siehe das Richardson-Maturitätsmodell. Der Artikel gibt Beispiele und erklärt vor allem, warum ein (sogenannter) SOAP-Dienst ein REST-Dienst der Stufe 0 ist (obwohl Stufe 0 eine geringe Übereinstimmung mit diesem Modell bedeutet, ist es nicht beleidigend und für viele Fälle immer noch nützlich).

Answer 2

Unter vielen anderen, die bereits in den vielen Antworten behandelt wurden, möchte ich hervorheben, dass SOAP es ermöglicht, einen Vertrag zu definieren, das WSDL, das die unterstützten Operationen, komplexen Typen usw. definiert. SOAP ist auf Operationen ausgerichtet, aber REST ist auf Ressourcen ausgerichtet. Persönlich würde ich SOAP für komplexe Schnittstellen zwischen internen Unternehmensanwendungen und REST für öffentliche, einfachere, zustandslose Schnittstellen mit der Außenwelt wählen.

Answer 3

Zusatz für:

++ Ein häufiger Fehler, der gemacht wird, wenn man sich REST nähert, besteht darin, es als "Webdienste mit URLs" zu betrachten – REST als einen weiteren Remote-Verfahrensaufruf (RPC) Mechanismus, ähnlich wie SOAP, aber aufgerufen über einfache HTTP-URLs und ohne die umfangreichen XML-Namensräume von SOAP.

++ Im Gegensatz dazu hat REST wenig mit RPC zu tun. Während RPC serviceorientiert ist und auf Handlungen und Verben fokussiert ist, ist REST ressourcenorientiert und betont die Dinge und Substantive, die eine Anwendung ausmachen.

Answer 4

Viele dieser Antworten haben vollständig vergessen, auf Hypermedia-Steuerungen (HATEOAS) einzugehen, was für REST vollkommen grundlegend ist. Einige andere haben es angesprochen, aber nicht so gut erklärt.

Dieser Artikel sollte den Unterschied zwischen den Konzepten erklären, ohne sich in einzelne SOAP-Funktionen zu verstricken.

Answer 5

REST-API

RESTful-APIs sind die bekannteste Art von API. REST steht für REpresentational State Transfer.

REST-APIs sind APIs, die standardisierte Prinzipien, Eigenschaften und Einschränkungen befolgen.

Sie können auf Ressourcen in der REST-API mit HTTP-Verben zugreifen.

REST-APIs arbeiten mit einem einfachen Anfrage/Antwort-System. Sie können eine Anfrage mit diesen HTTP-Methoden senden:

• GET
• POST
• PUT
• PATCH
• DELETE
• TRACE
• OPTIONS
• CONNECT
• HEAD

Hier sind die häufigsten HTTP-Verben

• GET (vorhandene Daten lesen)
• POST (neue Daten oder Antworten erstellen)
• PATCH (Daten aktualisieren)
• DELETE (Daten löschen)

Der Client kann Anfragen mit HTTP-Verben gefolgt von der Endpunkt machen.

Der Endpunkt (oder Pfad) ist die URL, die Sie anfordern. Der Pfad bestimmt die Ressource, die Sie anfordern.

Wenn Sie eine Anfrage an einen Endpunkt senden, antwortet er mit den relevanten Daten, meistens formatiert als JSON, XML, Klartext, Bilder, HTML und mehr.

REST-APIs können auch mit vielen verschiedenen Endpunkten entworfen werden, die verschiedene Arten von Daten zurückgeben. Der Zugriff auf mehrere Endpunkte mit einer REST-API erfordert verschiedene API-Aufrufe.

Eine tatsächliche RESTful-API folgt den folgenden fünf Einschränkungen:

1. Client-Server-Architektur
   Der Client fordert die Daten vom Server an, ohne Interpretation durch Dritte.

2. Zustandslosigkeit
   Zustandslosigkeit bedeutet, dass jede HTTP-Anforderung in einer vollständigen Isolation stattfindet. Jede Anfrage enthält die Informationen, die notwendig sind, um die Anfrage zu bearbeiten. Der Server verlässt sich nie auf Informationen aus früheren Anfragen. Es gibt keinen Zustand.

3. Cachebarkeit
   Antworten können explizit oder implizit als cachebar oder nicht-cachebar definiert werden, um Skalierbarkeit und Leistung zu verbessern. Beispielsweise kann das Aktivieren des Caches von GET-Anforderungen die Antwortzeiten von Anforderungen für Ressourcendaten verbessern.

4. Schichtung
   Verschiedene Schichten der API-Architektur sollten zusammenarbeiten und ein skalierbares System schaffen, das einfach zu aktualisieren oder anzupassen ist.

5. Einheitliche Schnittstelle
   Die Kommunikation zwischen Client und Server muss in einer standardisierten Sprache erfolgen, die unabhängig von beiden ist. Dies verbessert die Skalierbarkeit und Flexibilität.

REST-APIs sind eine gute Wahl für Projekte, die sein müssen

• Flexibel
• Skalierbar
• Schnell

SOAP-API

SOAP ist ein notwendiges Protokoll, das zur weit verbreiteten Verwendung von APIs beigetragen hat.

SOAP ist das Akronym für Simple Object Access Protocol.

SOAP ist ein standardisiertes Protokoll, das auf XML basiert, um Anfragen zu erstellen und Antworten zu erhalten.

Auch wenn SOAP auf XML basiert, wird das SOAP-Protokoll nach wie vor weitreichend genutzt.

SOAP-APIs machen Daten als Dienst verfügbar und werden typischerweise verwendet, wenn Transaktionen mit mehreren API-Aufrufen oder Anwendungen durchgeführt werden, bei denen Sicherheit im Vordergrund steht.

SOAP wurde ursprünglich 1998 für Microsoft entwickelt, um einen standardisierten Mechanismus zur Integration von Diensten im Internet unabhängig vom Betriebssystem, Objektmodell oder Programmiersprache bereitzustellen.

Das "S" in SOAP steht für Einfach, und das aus gutem Grund - SOAP kann mit weniger Komplexität verwendet werden, da es weniger Kodierung in der App-Schicht für Transaktionen, Sicherheit und andere Funktionen erfordert.

SOAP hat drei Hauptmerkmale:

1. Erweiterbarkeit der SOAP-API
   SOAP ermöglicht Erweiterungen, die robustere Funktionen wie Windows Server Security, Addressing und mehr einführen.

2. Neutralität der SOAP-API
   SOAP ist in der Lage, über eine Vielzahl von Protokollen wie UDP, JMS, SMTP, TCP und HTTP zu arbeiten.

3. Unabhängigkeit der SOAP-API
   SOAP-API-Antworten basieren rein auf XML. Daher sind SOAP-APIs plattform- und sprachunabhängig.

Entwickler diskutieren weiterhin über die Vor- und Nachteile der Verwendung von SOAP und REST. Der beste für Ihr Projekt wird derjenige sein, der Ihren Anforderungen entspricht.

• SOAP-APIs bleiben eine Top-Wahl für Unternehmens- und Regierungsorganisationen, die Sicherheit priorisieren, auch wenn REST den Bereich der Webanwendungen weitgehend dominiert hat.

• SOAP ist sicherer als REST, da es WS-Security für die Übertragung zusammen mit Secure-Socket-Layer verwendet.

• SOAP bietet auch eine bessere Transaktionssicherheit, was ein weiterer Grund dafür ist, warum SOAP historisch gesehen von der Bankenindustrie und anderen großen Unternehmen bevorzugt wurde.