SOAP vs REST (Unterschiede)

Ich habe Artikel über die Unterschiede zwischen SOAP und REST als Webdienst-Kommunikationsprotokoll gelesen, aber ich denke, dass die größten Vorteile von REST gegenüber SOAP folgende sind:

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

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

SOAP ist jedoch standardisierter (z. B. Sicherheit).

Bin ich in diesen Punkten richtig?

Leider gibt es viele Fehlinformationen und Missverständnisse rund um REST. Nicht nur Ihre Frage und die Antwort von @cmd spiegeln diese wider, sondern auch die meisten Fragen und Antworten zum Thema Stapelüberlauf.

SOAP und REST können nicht direkt verglichen werden, da das erste ein Protokoll ist (oder zumindest versucht) und das zweite ein Architekturstil ist. Dies ist wahrscheinlich eine der Ursachen für Verwirrung, da die Leute dazu neigen, REST jede HTTP-API aufzurufen, die nicht SOAP ist.

Der Hauptunterschied zwischen SOAP und REST besteht im Grad der Kopplung zwischen Client- und Server-Implementierungen. Ein SOAP-Client funktioniert wie eine benutzerdefinierte Desktop-Anwendung, die eng mit dem Server verbunden ist. Es gibt einen starren Vertrag zwischen Client und Server, und es wird erwartet, dass alles kaputt geht, wenn eine Seite etwas ändert. Nach jeder Änderung müssen Sie ständig aktualisiert werden. Es ist jedoch einfacher festzustellen, ob der Vertrag eingehalten wird.

Ein REST-Client ähnelt eher einem Browser. Es ist ein generischer Client, der weiß, wie man ein Protokoll und standardisierte Methoden verwendet, und eine Anwendung muss dazu passen. Sie verletzen die Protokollstandards nicht, indem Sie zusätzliche Methoden erstellen. Sie nutzen die Standardmethoden und erstellen die Aktionen mit ihnen auf Ihrem Medientyp. Wenn es richtig gemacht wird, gibt es weniger Kopplung und Änderungen können eleganter behandelt werden. Ein Client soll einen REST-Service ohne Kenntnis der API eingeben, mit Ausnahme des Einstiegspunkts und des Medientyps. In SOAP benötigt der Client Vorkenntnisse zu allem, was er verwenden wird, oder er beginnt nicht einmal mit der Interaktion. Darüber hinaus kann ein REST-Client durch Code-on-Demand erweitert werden, der vom Server selbst bereitgestellt wird.

Ich denke, dies sind die entscheidenden Punkte, um zu verstehen, worum es bei REST geht und wie es sich von SOAP unterscheidet:

• REST ist protokollunabhängig. Es ist nicht an HTTP gekoppelt. Ähnlich wie Sie einem FTP-Link auf einer Website folgen können, kann eine REST-Anwendung jedes Protokoll verwenden, für das es ein standardisiertes URI-Schema gibt.

• REST ist keine Zuordnung von CRUD zu HTTP-Methoden. Lesen Sie diese Antwort, um eine ausführliche Erklärung dazu zu erhalten.

• REST ist so standardisiert wie die Teile, die Sie verwenden. Sicherheit und Authentifizierung in HTTP sind standardisiert. Dies verwenden Sie also, wenn Sie REST über HTTP ausführen.

• REST ist nicht REST ohne Hypermedia und HATEOAS . Dies bedeutet, dass ein Client nur den Einstiegspunkt-URI kennt und die Ressourcen Links zurückgeben sollen, denen der Client folgen soll. Diese ausgefallenen Dokumentationsgeneratoren, die URI-Muster für alles angeben, was Sie in einer REST-API tun können, verfehlen den Punkt vollständig. Sie dokumentieren nicht nur etwas, das dem Standard entsprechen soll, sondern wenn Sie dies tun, koppeln Sie den Client an einen bestimmten Moment in der Entwicklung der API, und alle Änderungen an der API müssen dokumentiert und angewendet werden. oder es wird brechen.

• REST ist der architektonische Stil des Webs. Wenn Sie Stack Overflow eingeben, wissen Sie, was ein Benutzer, eine Frage und eine Antwort sind, Sie kennen die Medientypen und die Website bietet Ihnen die Links zu diesen. Eine REST-API muss dasselbe tun. Wenn wir das Web so gestalten würden, wie die Leute denken, dass REST durchgeführt werden sollte, anstatt eine Homepage mit Links zu Fragen und Antworten zu haben, hätten wir eine statische Dokumentation, in der erklärt wird, dass Sie zum Anzeigen einer Frage den URI verwenden stackoverflow.com/questions/<id>müssen. Ersetzen Sie die ID durch die Question.id und fügen Sie diese in Ihren Browser ein. Das ist Unsinn, aber genau das halten viele Leute für REST.

Dieser letzte Punkt kann nicht genug betont werden. Wenn Ihre Clients URIs aus Vorlagen in der Dokumentation erstellen und keine Links in den Ressourcendarstellungen erhalten, ist dies kein REST. Roy Fielding, der Autor von REST, machte in diesem Blog-Beitrag deutlich: REST-APIs müssen hypertextgesteuert sein .

Vor diesem Hintergrund werden Sie feststellen, dass REST möglicherweise nicht auf XML beschränkt ist. Um es jedoch mit jedem anderen Format korrekt auszuführen, müssen Sie ein Format für Ihre Links entwerfen und standardisieren. Hyperlinks sind Standard in XML, jedoch nicht in JSON. Es gibt Standardentwürfe für JSON wie HAL .

Schließlich ist REST nicht jedermanns Sache, und ein Beweis dafür ist, wie die meisten Menschen ihre Probleme mit den HTTP-APIs, die sie fälschlicherweise als REST bezeichnet haben, sehr gut lösen und sich niemals darüber hinaus wagen. REST ist manchmal schwierig, besonders am Anfang, aber es zahlt sich im Laufe der Zeit aus, da die Entwicklung auf der Serverseite einfacher ist und der Client widerstandsfähig gegenüber Änderungen ist. Wenn Sie etwas schnell und einfach erledigen müssen, kümmern Sie sich nicht darum, REST richtig zu machen. Es ist wahrscheinlich nicht das, wonach Sie suchen. Wenn Sie etwas brauchen, das jahrelang oder sogar jahrzehntelang online bleiben muss, dann ist REST genau das Richtige für Sie.

RESTvs SOAPist nicht die richtige Frage.

RESTIm Gegensatz SOAPist kein Protokoll.

RESTist ein Architekturstil und ein Design für netzwerkbasierte Softwarearchitekturen.

RESTKonzepte werden als Ressourcen bezeichnet. Eine Darstellung einer Ressource muss zustandslos sein. Es wird über einen Medientyp dargestellt. Einige Beispiele für Medientypen umfassen XML, JSONund RDF. Ressourcen werden von Komponenten manipuliert. Komponenten fordern Ressourcen an und bearbeiten sie über eine einheitliche Standardschnittstelle. Im Fall von HTTP, diese Schnittstelle besteht aus Standard - HTTP - ops zB GET, PUT, POST, DELETE.

@ Abdulaziz 'Frage beleuchtet die Tatsache, dass RESTund HTTPoft zusammen verwendet werden. Dies liegt hauptsächlich an der Einfachheit von HTTP und seiner sehr natürlichen Zuordnung zu RESTful-Prinzipien.

Grundlegende REST-Prinzipien

Client-Server-Kommunikation

Client-Server-Architekturen weisen eine sehr unterschiedliche Trennung von Bedenken auf. Alle im RESTful-Stil erstellten Anwendungen müssen grundsätzlich auch Client-Server sein.

Staatenlos

Für jede Clientanforderung an den Server muss der Status vollständig dargestellt werden. Der Server muss in der Lage sein, die Clientanforderung vollständig zu verstehen, ohne einen Serverkontext oder einen Serversitzungsstatus zu verwenden. Daraus folgt, dass der gesamte Status auf dem Client beibehalten werden muss.

Cacheable

Cache-Einschränkungen können verwendet werden, wodurch Antwortdaten als zwischenspeicherbar oder nicht zwischenspeicherbar markiert werden können. Alle als zwischenspeicherbar gekennzeichneten Daten können als Antwort auf dieselbe nachfolgende Anforderung wiederverwendet werden.

Einheitliche Schnittstelle

Alle Komponenten müssen über eine einzige einheitliche Schnittstelle interagieren. Da die gesamte Komponenteninteraktion über diese Schnittstelle erfolgt, ist die Interaktion mit verschiedenen Diensten sehr einfach. Die Schnittstelle ist die gleiche! Dies bedeutet auch, dass Implementierungsänderungen isoliert vorgenommen werden können. Solche Änderungen wirken sich nicht auf die grundlegende Komponenteninteraktion aus, da die einheitliche Schnittstelle immer unverändert bleibt. Ein Nachteil ist, dass Sie mit der Schnittstelle stecken bleiben. Wenn durch Ändern der Benutzeroberfläche eine Optimierung für einen bestimmten Dienst bereitgestellt werden könnte, haben Sie kein Glück, da REST dies verbietet. Positiv zu vermerken ist jedoch, dass REST für das Web optimiert ist, weshalb REST über HTTP unglaublich beliebt ist!

Die obigen Konzepte stellen definierende Merkmale von REST dar und unterscheiden die REST-Architektur von anderen Architekturen wie Webdiensten. Es ist nützlich zu beachten, dass ein REST-Service ein Web-Service ist, ein Web-Service jedoch nicht unbedingt ein REST-Service.

Sehen Sie dieses Blog Post auf REST - Design - Prinzipien für weitere Details über REST und die oben genannten Kugeln.

BEARBEITEN: Aktualisieren Sie den Inhalt basierend auf Kommentaren

SOAP ( Simple Object Access Protocol ) und REST ( Representation State Transfer ) sind beide auf ihre Weise wunderschön. Also vergleiche ich sie nicht. Stattdessen versuche ich, das Bild darzustellen, wenn ich lieber REST und SOAP verwendet habe.

Was ist Nutzlast?

Wenn Daten über das Internet gesendet werden, enthält jede übertragene Einheit sowohl Header-Informationen als auch die tatsächlich gesendeten Daten. Der Header identifiziert die Quelle und das Ziel des Pakets, während die tatsächlichen Daten als Nutzdaten bezeichnet werden . Im Allgemeinen sind die Nutzdaten die Daten, die im Auftrag einer Anwendung übertragen werden, und die vom Zielsystem empfangenen Daten.

Jetzt muss ich zum Beispiel ein Telegramm senden und wir alle wissen, dass die Kosten des Telegramms von einigen Wörtern abhängen.

Sagen Sie mir also unter den unten genannten zwei Nachrichten, welche ist billiger zu senden?

<name>Arin</name>

oder

"name": "Arin"

Ich weiß, dass Ihre Antwort die zweite sein wird, obwohl beide dieselbe Nachricht darstellen. Die zweite ist in Bezug auf die Kosten billiger.

Ich versuche zu sagen, dass das Senden von Daten über das Netzwerk im JSON-Format in Bezug auf die Nutzlast billiger ist als das Senden im XML-Format .

Hier ist der erste Vorteil oder die ersten Vorteile von REST gegenüber SOAP . SOAP unterstützt nur XML, aber REST unterstützt andere Formate wie Text, JSON, XML usw. Und wir wissen bereits, wenn wir Json verwenden, sind wir in Bezug auf die Nutzlast definitiv an einem besseren Ort.

Jetzt unterstützt SOAP das einzige XML, hat aber auch seine Vorteile.

Ja wirklich! Wie?

SOAP setzt auf drei Arten auf XML Envelope - das definiert, was in der Nachricht enthalten ist und wie sie verarbeitet wird.

Eine Reihe von Codierungsregeln für Datentypen und schließlich das Layout der gesammelten Prozeduraufrufe und -antworten.

Dieser Umschlag wird über einen Transport (HTTP / HTTPS) gesendet, und ein RPC (Remote Procedure Call) wird ausgeführt, und der Umschlag wird mit Informationen in einem XML-formatierten Dokument zurückgegeben.

Der wichtige Punkt ist, dass einer der Vorteile von SOAP die Verwendung des „generischen“ Transports ist , REST jedoch HTTP / HTTPS verwendet . SOAP kann fast jeden Transport zum Senden der Anfrage verwenden, REST jedoch nicht. Hier haben wir also den Vorteil, SOAP zu verwenden.

Wie ich bereits im obigen Absatz erwähnt habe, verwendet REST HTTP / HTTPS. Gehen Sie also etwas tiefer in diese Wörter ein.

Wenn es sich um REST über HTTP handelt, werden alle angewendeten Sicherheitsmaßnahmen für HTTP vererbt. Dies wird als Sicherheit auf Transportebene bezeichnet und sichert Nachrichten nur, während sie sich im Kabel befinden. Sobald Sie sie auf der anderen Seite zugestellt haben, wissen Sie es nicht Wie viele Phasen muss es durchlaufen, bevor der tatsächliche Punkt erreicht ist, an dem die Daten verarbeitet werden? Und natürlich könnten all diese Phasen etwas anderes als HTTP verwenden. Ruhe ist also nicht ganz sicherer, oder?

SOAP unterstützt SSL ebenso wie REST und WS-Security, wodurch einige Sicherheitsfunktionen für Unternehmen hinzugefügt werden. WS-Security bietet Schutz von der Erstellung der Nachricht bis zum Verbrauch . Für die Sicherheit auf Transportebene können wir also eine Lücke finden, die mit WS-Security verhindert werden kann.

Abgesehen davon, da REST durch sein HTTP-Protokoll eingeschränkt ist , ist seine Transaktionsunterstützung weder ACID-konform noch kann es eine zweiphasige Festschreibung über verteilte transnationale Ressourcen hinweg ermöglichen.

SOAP bietet jedoch umfassende Unterstützung sowohl für das ACID-basierte Transaktionsmanagement für kurzlebige Transaktionen als auch für das kompensationsbasierte Transaktionsmanagement für langfristige Transaktionen. Es unterstützt auch das zweiphasige Festschreiben über verteilte Ressourcen hinweg .

Ich ziehe keine Schlussfolgerung, aber ich werde einen SOAP-basierten Webdienst bevorzugen, während Sicherheit, Transaktion usw. die Hauptanliegen sind.

Hier ist das "Java EE 6 Tutorial", in dem gesagt wurde, dass ein RESTful-Design angemessen sein kann, wenn die folgenden Bedingungen erfüllt sind . Guck mal.

Ich hoffe, Sie haben es genossen, meine Antwort zu lesen.

REST ( RE Präsentations - S tate T ransfer)
RE Präsentations - S tate eines Objekts ist T ransferred ist REST dh wir Objekt nicht senden, wir Zustand Objekt senden. REST ist ein architektonischer Stil. Es definiert nicht so viele Standards wie SOAP. REST dient zum Offenlegen öffentlicher APIs (z. B. Facebook-API, Google Maps-API) über das Internet, um CRUD-Vorgänge für Daten zu verarbeiten. REST konzentriert sich auf den Zugriff auf benannte Ressourcen über eine einzige konsistente Schnittstelle.

SOAP ( S ople O bject A ccess P rotocol)
SOAP bringt ein eigenes Protokoll mit und konzentriert sich darauf, Teile der Anwendungslogik (keine Daten) als Dienste verfügbar zu machen. SOAP macht Operationen verfügbar. SOAP konzentriert sich auf den Zugriff auf benannte Operationen. Jede Operation implementiert eine Geschäftslogik. Obwohl SOAP allgemein als Webdienste bezeichnet wird, ist dies eine falsche Bezeichnung. SOAP hat wenig oder gar nichts mit dem Web zu tun. REST bietet echte Webdienste basierend auf URIs und HTTP.

Warum ruhen?

• Da REST Standard-HTTP verwendet, ist es in nahezu jeder Hinsicht viel einfacher.
• REST ist einfacher zu implementieren, erfordert weniger Bandbreite und Ressourcen.
• REST erlaubt viele verschiedene Datenformate, wobei SOAP nur XML erlaubt.
• REST ermöglicht aufgrund der Unterstützung von JSON eine bessere Unterstützung für Browser-Clients.
• REST bietet eine bessere Leistung und Skalierbarkeit. REST-Lesevorgänge können zwischengespeichert werden, SOAP-basierte Lesevorgänge können nicht zwischengespeichert werden.
• Wenn Sicherheit kein großes Problem darstellt und wir nur über begrenzte Ressourcen verfügen. Oder wir möchten eine API erstellen, die von anderen Entwicklern problemlos öffentlich verwendet werden kann. Dann sollten wir uns für REST entscheiden.
• Wenn wir zustandslose CRUD-Operationen benötigen, wählen Sie REST.
• REST wird häufig in sozialen Medien, Web-Chat, mobilen Diensten und öffentlichen APIs wie Google Maps verwendet.
• Der RESTful-Dienst gibt abhängig vom Anforderungsheaderparameter "Accept" als application/xmloder application/jsonfür POST und / /user/1234.jsonoder GET /user/1234.xmlfür GET verschiedene MediaTypes für dieselbe Ressource zurück .
• REST-Services sollen von der clientseitigen Anwendung und nicht direkt vom Endbenutzer aufgerufen werden.
• ST in REST stammt aus S tate T ransfer. Sie übertragen den Status, anstatt ihn vom Server speichern zu lassen. Dadurch werden REST-Services skalierbar.

Warum SOAP?

• SOAP ist nicht sehr einfach zu implementieren und erfordert mehr Bandbreite und Ressourcen.
• Die SOAP-Nachrichtenanforderung wird im Vergleich zu REST langsamer verarbeitet und verwendet keinen Web-Caching-Mechanismus.
• WS-Sicherheit: Während SOAP SSL unterstützt (genau wie REST), unterstützt es auch WS-Sicherheit, die einige Sicherheitsfunktionen für Unternehmen hinzufügt.
• WS-AtomicTransaction: Benötigen Sie ACID-Transaktionen über einen Dienst, benötigen Sie SOAP.
• WS-ReliableMessaging: Wenn Ihre Anwendung eine asynchrone Verarbeitung und ein garantiertes Maß an Zuverlässigkeit und Sicherheit benötigt. Rest verfügt nicht über ein Standardnachrichtensystem und erwartet, dass Clients Kommunikationsfehler durch erneutes Versuchen beheben.
• Wenn die Sicherheit ein wichtiges Anliegen ist und die Ressourcen nicht begrenzt sind, sollten wir SOAP-Webdienste verwenden. Wenn wir beispielsweise einen Webdienst für Zahlungsgateways, Finanz- und Telekommunikationsarbeiten erstellen, sollten wir uns für SOAP entscheiden, da hier hohe Sicherheit erforderlich ist.

Quelle1
Quelle2

Unterschied zwischen Ruhe und Seife

SEIFE

1. SOAP ist ein Protokoll.
2. SOAP steht für Simple Object Access Protocol.
3. SOAP kann REST nicht verwenden, da es sich um ein Protokoll handelt.
4. SOAP verwendet Dienstschnittstellen, um die Geschäftslogik verfügbar zu machen.
5. SOAP definiert Standards, die strikt eingehalten werden müssen.
6. SOAP erfordert mehr Bandbreite und Ressourcen als REST.
7. SOAP definiert seine eigene Sicherheit.
8. SOAP erlaubt nur das XML-Datenformat.
9. SOAP ist weniger bevorzugt als REST.

SICH AUSRUHEN

1. REST ist ein architektonischer Stil.
2. REST steht für Representational State Transfer.
3. REST kann SOAP-Webdienste verwenden, da es sich um ein Konzept handelt und jedes Protokoll wie HTTP oder SOAP verwenden kann.
4. REST verwendet URI, um die Geschäftslogik verfügbar zu machen.
5. REST definiert nicht zu viele Standards wie SOAP.
6. REST benötigt weniger Bandbreite und Ressourcen als SOAP.
7. RESTful-Webdienste erben Sicherheitsmaßnahmen vom zugrunde liegenden Transport.
8. REST erlaubt verschiedene Datenformate wie Nur-Text, HTML, XML, JSON usw.
9. REST bevorzugter als SOAP.

Weitere Details finden Sie hier

IMHO kann man SOAP und REST nicht vergleichen, wo das zwei verschiedene Dinge sind.

SOAP ist ein Protokoll und REST ist ein Software-Architekturmuster. Im Internet gibt es viele Missverständnisse zwischen SOAP und REST .

SOAP definiert das XML-basierte Nachrichtenformat, mit dem Webdienst-fähige Anwendungen über das Internet miteinander kommunizieren. Zu diesem Zweck benötigen die Anwendungen Vorkenntnisse über den Nachrichtenvertrag, die Datentypen usw.

REST stellt den Status (als Ressourcen) eines Servers aus einer URL dar. Es ist zustandslos und Clients sollten keine Vorkenntnisse haben, um mit dem Server zu interagieren, die über das Verständnis von Hypermedia hinausgehen.

Zunächst einmal: offiziell, wäre die richtige Frage web services + WSDL + SOAPvs REST.

Da der Webdienst zwar im losen Sinne verwendet wird, wenn er das HTTP-Protokoll zum Übertragen von Daten anstelle von Webseiten verwendet, handelt es sich offiziell um eine sehr spezifische Form dieser Idee. Nach der Definition ist REST kein "Webdienst".

In der Praxis ignoriert dies jedoch jeder, also ignorieren wir es auch

Es gibt bereits technische Antworten, daher werde ich versuchen, eine gewisse Intuition zu vermitteln.

Angenommen, Sie möchten eine Funktion in einem Remotecomputer aufrufen, der in einer anderen Programmiersprache implementiert ist (dies wird häufig als Remoteprozeduraufruf / RPC bezeichnet ). Angenommen, die Funktion befindet sich unter einer bestimmten URL, die von der Person bereitgestellt wird, die sie geschrieben hat. Sie müssen (irgendwie) eine Nachricht senden und eine Antwort erhalten. Es sind also zwei Hauptfragen zu berücksichtigen.

• Was ist das Format der Nachricht, die Sie senden sollten
• Wie soll die Nachricht hin und her getragen werden?

Für die erste Frage lautet die offizielle Definition WSDL . Dies ist eine XML-Datei, die in detailliertem und striktem Format beschreibt, welche Parameter, welche Typen, Namen, Standardwerte, Namen der aufzurufenden Funktion usw. vorhanden sind. Eine Beispiel-WSDL hier zeigt, dass die Datei menschlich ist -lesbar (aber nicht leicht).

Für die zweite Frage gibt es verschiedene Antworten. In der Praxis wird jedoch nur SOAP verwendet . Die Hauptidee ist: Wickeln Sie das vorherige XML (die eigentliche Nachricht) in ein weiteres XML (das Codierungsinformationen und andere hilfreiche Informationen enthält) und senden Sie es über HTTP. Die POST-Methode des HTTP wird zum Senden der Nachricht verwendet, da immer ein Text vorhanden ist .

Die Hauptidee dieses gesamten Ansatzes besteht darin, dass Sie einer Funktion , dh einer Aktion, eine URL zuordnen . Wenn Sie also eine Kundenliste auf einem Server haben und eine anzeigen / aktualisieren / löschen möchten, müssen Sie 3 URLs haben:

• myapp/read-customer Geben Sie im Nachrichtentext die ID des zu lesenden Kunden weiter.
• myapp/update-customer und im Körper die ID des Kunden sowie die neuen Daten weitergeben
• myapp/delete-customer und die ID im Körper

Der REST-Ansatz sieht die Dinge anders. Eine URL sollte keine Aktion darstellen, sondern eine Sache ( im REST-Jargon als Ressource bezeichnet ). Da das HTTP-Protokoll (das wir bereits verwenden) Verben unterstützt, verwenden Sie diese Verben, um anzugeben, welche Aktionen für das Objekt ausgeführt werden sollen.

Beim REST-Ansatz wird also die Kundennummer 12 auf der URL gefunden myapp/customers/12. Um die Kundendaten anzuzeigen, geben Sie die URL mit einer GET-Anfrage ein. Um es zu löschen, dieselbe URL mit einem DELETE-Verb. Um es erneut zu aktualisieren, dieselbe URL mit einem POST-Verb und den neuen Inhalt im Anforderungshauptteil.

Weitere Informationen zu den Anforderungen, die ein Service erfüllen muss, um als wirklich RESTful zu gelten, finden Sie im Richardson-Reifegradmodell . Der Artikel enthält Beispiele und erklärt vor allem, warum ein (sogenannter) SOAP-Service ein REST-Service der Stufe 0 ist (obwohl Stufe 0 eine geringe Konformität mit diesem Modell bedeutet, ist es nicht anstößig und dennoch nützlich in vielen Fällen).

Unter vielen anderen, die bereits in den vielen Antworten behandelt wurden, möchte ich hervorheben, dass SOAP die Definition eines Vertrags ermöglicht, der WSDL, die die unterstützten Vorgänge, komplexen Typen usw. definiert. SOAP ist auf Vorgänge ausgerichtet, REST jedoch auf Ressourcen. 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 auswählen.

Ergänzung für:

++ Ein Fehler, der häufig bei der Annäherung an REST gemacht wird, besteht darin, es als „Webdienste mit URLs“ zu betrachten - REST als einen anderen RPC-Mechanismus (Remote Procedure Call) wie SOAP zu betrachten, der jedoch über einfache HTTP-URLs und ohne SOAP aufgerufen wird XML-Namespaces.

++ Im Gegenteil, REST hat wenig mit RPC zu tun. Während RPC serviceorientiert ist und sich auf Aktionen und Verben konzentriert, ist REST ressourcenorientiert und betont die Dinge und Substantive, aus denen eine Anwendung besteht.

Viele dieser Antworten haben völlig vergessen, Hypermedia-Kontrollen (HATEOAS) zu erwähnen, die für REST von grundlegender Bedeutung sind. Einige andere berührten es, erklärten es aber nicht so gut.

Dieser Artikel sollte den Unterschied zwischen den Konzepten erläutern, ohne auf bestimmte SOAP-Funktionen einzugehen.