it-swarm.com.de

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 für REST gegenüber SOAP 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 Klartext/JSON/XML senden.

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

Also, bin ich in diesen Punkten richtig?

1183
Abdulaziz

Leider gibt es viele Fehlinformationen und Missverständnisse in Bezug auf REST. Nicht nur Ihre Frage und das Antwort von @cmd spiegeln diese wider, sondern auch die meisten Fragen und Antworten zum Thema Stack Overflow.

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

Der Hauptunterschied zwischen SOAP und REST ist der Grad der Kopplung zwischen Client- und Serverimplementierungen. Ein SOAP -Client funktioniert wie eine benutzerdefinierte Desktopanwendung, 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. Sie müssen nach jeder Änderung ständig aktualisiert werden. Es ist jedoch einfacher festzustellen, ob der Vertrag eingehalten wird.

Ein REST -Client ähnelt eher einem Browser. Es ist ein allgemeiner Client, der mit einem Protokoll und standardisierten Methoden vertraut ist und in den eine Anwendung passen muss. Sie verstoßen nicht gegen die Protokollstandards, indem Sie zusätzliche Methoden erstellen. Sie greifen auf die Standardmethoden zurück und erstellen die entsprechenden Aktionen für Ihren Medientyp. Wenn es richtig gemacht wird, gibt es weniger Kopplung und Änderungen können eleganter behandelt werden. Ein Client muss einen REST -Dienst ohne Kenntnis der API eingeben, mit Ausnahme des Einstiegspunkts und des Medientyps. In SOAP benötigt der Client Vorkenntnisse über alles, 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. Das klassische Beispiel ist JavaScript-Code, der zur Steuerung der Interaktion mit einem anderen Dienst auf der Clientseite verwendet 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 this , 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, daher verwenden Sie diese Option, 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. Jene ausgefallenen Dokumentationsgeneratoren, die URI-Muster für alles geben, 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, verbinden Sie den Client mit einem 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 in den Stapelüberlauf eintreten, 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 getan werden sollte, anstatt eine Homepage mit Links zu Fragen und Antworten zu haben, hätten wir eine statische Dokumentation, die dies erklärt, um eine Frage anzuzeigen, Sie müssen den URI stackoverflow.com/questions/<id> nehmen, die ID durch die Question.id ersetzen und diese in Ihren Browser einfügen. Das ist Unsinn, aber viele Leute denken, dass dies REST ist.

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, hat in diesem Blogbeitrag Folgendes klargestellt: REST-APIs müssen hypertextgesteuert sein .

In Anbetracht des oben Gesagten werden Sie feststellen, dass REST möglicherweise nicht auf XML beschränkt ist. Um dies in jedem anderen Format korrekt zu tun, müssen Sie einige Formate für Ihre Links entwerfen und standardisieren. Hyperlinks sind in XML Standard, 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, dass die meisten Leute ihre Probleme sehr gut mit den HTTP-APIs lösen, die sie fälschlicherweise REST genannt haben, und sich niemals darüber hinaus wagen. REST ist manchmal schwer zu tun, besonders am Anfang, aber es lohnt sich im Laufe der Zeit mit einer einfacheren Entwicklung auf der Serverseite und der Widerstandsfähigkeit des Clients gegenüber Änderungen. Wenn Sie schnell und einfach etwas 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 das Richtige für Sie.

1687
Pedro Werneck

REST vs SOAP ist nicht ​​ die richtige Frage.

REST ist im Gegensatz zu SOAPnicht ​​ ein Protokoll.

REST ist ein Architekturstil und ein Entwurf für netzwerkbasierte Softwarearchitekturen.

REST Konzepte werden als Ressourcen bezeichnet. Eine Darstellung einer Ressource muss zustandslos sein. Es wird über einen Medientyp dargestellt. Einige Beispiele für Medientypen sind XML, JSON und RDF. Ressourcen werden von Komponenten manipuliert. Komponenten fordern Ressourcen über eine einheitliche Standardschnittstelle an und bearbeiten sie. Im Falle von HTTP besteht diese Schnittstelle aus Standard-HTTP-Operationen, z. GET, PUT, POST, DELETE.

@ Abdulaziz 'Frage beleuchtet die Tatsache, dass REST und HTTP oft zusammen verwendet werden. Dies liegt in erster Linie an der Einfachheit von HTTP und seiner sehr natürlichen Zuordnung zu RESTful-Prinzipien.

Grundlegende REST Prinzipien

Client-Server-Kommunikation

Client-Server-Architekturen unterscheiden sich stark voneinander. Alle im RESTful-Stil erstellten Anwendungen müssen grundsätzlich auch Client-Server sein.

Staatenlos

Für jede Client-Anforderung 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 alle Status auf dem Client beibehalten werden müssen.

Cacheable

Cachebeschränkungen können verwendet werden, so dass Antwortdaten als zwischenspeicherbar oder nicht zwischenspeicherbar markiert werden können. Daten, die als zwischenspeicherbar markiert sind, können als Antwort auf dieselbe nachfolgende Anforderung wiederverwendet werden.

niform Interface

Alle Komponenten müssen über eine einzige einheitliche Schnittstelle miteinander interagieren. Da die Interaktion aller Komponenten ü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 Interaktion grundlegender Komponenten aus, da die einheitliche Schnittstelle immer unverändert bleibt. Ein Nachteil ist, dass Sie mit der Schnittstelle stecken. Wenn eine Optimierung für einen bestimmten Dienst durch Ändern der Schnittstelle bereitgestellt werden könnte, haben Sie Pech, da REST dies verbietet. Auf der positiven Seite ist jedoch REST für das Web optimiert, daher ist REST über HTTP unglaublich beliebt!

Die obigen Konzepte stellen definierende Merkmale von REST dar und unterscheiden die REST - Architektur von anderen Architekturen wie Webservices. Beachten Sie, dass ein REST -Dienst ein Webdienst ist, ein Webdienst jedoch nicht unbedingt ein REST -Dienst.

In diesem Blog post on REST Design Principles finden Sie weitere Informationen zu REST und den oben genannten Aufzählungszeichen.

EDIT: Inhalte basierend auf Kommentaren aktualisieren

277
cmd

SOAP ( Simple Object Access Protocol ) und REST ( Repräsentationsstatusübertragung ) beide sind auf ihre Weise schön. Also vergleiche ich sie nicht. Stattdessen versuche ich, das Bild abzubilden, als ich REST und als SOAP vorgezogen 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 Daten, die vom Zielsystem empfangen werden.

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

Also sag mir unter den beiden unten genannten Nachrichten, welche ist billiger zu senden?

<name>Arin</name>

oder

"name": "Arin"

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

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

Hier ist der erste Vorteil von REST gegenüber SOAP . SOAP unterstützt nur XML, aber REST unterstützt verschiedene Formate wie Text, JSON, XML usw. Und wir wissen bereits, wenn wir Json verwenden, sind wir in Bezug auf die Nutzlast definitiv besser aufgestellt .

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

Wirklich! Wie?

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

Eine Reihe von Codierungsregeln für Datentypen und schließlich das Layout der erfassten 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 aber REST verwendet HTTP/HTTPS . SOAP kann fast jeden Transport zum Senden der Anforderung 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“ .

Wenn es sich um REST über HTTP handelt, werden alle auf HTTP angewendeten Sicherheitsmaßnahmen vererbt. Dies wird als Transportebenensicherheit und bezeichnet Es sichert Nachrichten nur, während es sich innerhalb des Kabels befindet , aber sobald Sie es auf der anderen Seite abgeliefert haben, wissen Sie nicht, wie viele Phasen es gehen muss durch, bevor der tatsächliche Punkt erreicht wird, an dem die Daten verarbeitet werden. Und natürlich könnten alle diese Phasen etwas anderes als HTTP verwenden. Also ist Ruhe nicht ganz sicherer, oder?

Aber SOAP unterstützt SSL genauso wie REST zusätzlich WS-Security , das einige Sicherheitsfunktionen für Unternehmen hinzufügt. WS-Security bietet Schutz vor dem Erstellen der Nachricht zum Verbrauch . Für die Sicherheit auf Transportebene haben wir also eine Lücke gefunden, die mit WS-Security verhindert werden kann.

Da REST durch das HTTP-Protokoll begrenzt ist, ist die Transaktionsunterstützung weder ACID-kompatibel noch kann sie ein zweiphasiges Commit für verteilte transnationale Ressourcen bereitstellen.

Aber SOAP bietet umfassende Unterstützung sowohl für ACID-basiertes Transaktionsmanagement für kurzlebige Transaktionen als auch für vergütungsbasiertes Transaktionsmanagement für lang laufende Transaktionen . Es unterstützt auch das zweiphasige Festschreiben über verteilte Ressourcen .

Ich ziehe keine Schlussfolgerung vor, bevorzuge jedoch SOAP-basierten Webdienst, wobei Sicherheit, Transaktion usw. die Hauptanliegen sind.

Hier ist das "The Java EE 6 Tutorial", in dem es heißt: Ein RESTful-Design kann angemessen sein, wenn die folgenden Bedingungen erfüllt sind . Guck mal.

Hoffe es hat Ihnen Spaß gemacht, meine Antwort zu lesen.

225
Bacteria

REST (RE Präsentations S tate T ransfer)
RE presentational S tate of Ein Objekt wird T übertragen wird REST dh wir senden kein Objekt, wir senden den Status des Objekts. REST ist ein architektonischer Stil. Es definiert nicht so viele Standards wie SOAP. REST dient zum Offenlegen von öffentlichen APIs (d. H. 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 imple O bject A ccess P rotocol)
SOAP bringt ein eigenes Protokoll mit und konzentriert sich darauf, Teile der Anwendungslogik (nicht Daten) als Dienste bereitzustellen. SOAP macht Operationen verfügbar. SOAP konzentriert sich auf den Zugriff auf benannte Operationen. Jede Operation implementiert eine bestimmte Geschäftslogik. Obwohl SOAP im Allgemeinen als Webservices bezeichnet wird, ist dies eine falsche Bezeichnung. SOAP hat wenig oder gar nichts mit dem Web zu tun. REST stellt echte Webdienste bereit, die auf URIs und HTTP basieren.

Warum REST?

  • Da REST Standard-HTTP verwendet, ist dies in nahezu jeder Hinsicht einfacher.
  • REST ist einfacher zu implementieren, benötigt weniger Bandbreite und Ressourcen.
  • REST lässt viele verschiedene Datenformate zu, wobei SOAP nur XML zulässt.
  • REST ermöglicht eine bessere Unterstützung für Browser-Clients, da JSON unterstützt wird.
  • REST bietet eine bessere Leistung und Skalierbarkeit. REST Lesevorgänge können zwischengespeichert werden, SOAP Lesevorgänge können nicht zwischengespeichert werden.
  • Wenn Sicherheit kein großes Problem ist 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-Service gibt verschiedene Medientypen für dieselbe Ressource zurück, abhängig vom Anforderungsheaderparameter "Accept" als application/xml oder application/json für POST und /user/1234.json oder GET /user/1234.xml für GET.
  • REST-Services sollen von der clientseitigen Anwendung und nicht vom Endbenutzer direkt aufgerufen werden.
  • ST in REST stammt aus S tate T übertragen. Wenn Sie den Status übertragen, anstatt ihn vom Server speichern zu lassen, werden REST Dienste skalierbar.

Warum SOAP?

  • SOAP ist nicht sehr einfach zu implementieren und erfordert mehr Bandbreite und Ressourcen.
  • 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 Standardmessagingsystem und erwartet, dass Clients Kommunikationsfehler beheben, indem sie es erneut versuchen.
  • Wenn die Sicherheit ein wichtiges Anliegen ist und die Ressourcen nicht begrenzt sind, sollten wir SOAP Webservices verwenden. Wenn wir beispielsweise einen Web-Service für Zahlungs-Gateways, Finanz- und Telekommunikationsdienste erstellen, sollten wir uns für SOAP entscheiden, da hier eine hohe Sicherheit erforderlich ist.

enter image description here

source1
source2

117
Premraj

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 Serviceschnittstellen, um die Geschäftslogik verfügbar zu machen.
  5. SOAP definiert Standards, die genau eingehalten werden müssen.
  6. SOAP benötigt 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.

REST

  1. REST ist ein architektonischer Stil.
  2. REST steht für Representational State Transfer.
  3. REST kann SOAP Webservices verwenden, da dies ein Konzept ist und jedes Protokoll wie HTTP, SOAP verwendet werden kann.
  4. REST verwendet URI, um Geschäftslogik verfügbar zu machen.
  5. REST definiert nicht zu viele Standards wie SOAP.
  6. REST erfordert weniger Bandbreite und Ressourcen als SOAP.
  7. RESTful Web Services erben Sicherheitsmaßnahmen vom zugrunde liegenden Transport.
  8. REST erlaubt verschiedene Datenformate wie Plain Text, HTML, XML, JSON etc.
  9. REST bevorzugter als SOAP.

Weitere Details finden Sie unter hier

44
Rex

IMHO können Sie SOAP und REST nicht vergleichen, wo das zwei verschiedene Dinge sind.

SOAP ist ein Protokoll und REST ist eine Softwarearchitektur Muster. Im Internet gibt es viele Missverständnisse für SOAP vs 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 über eine URL dar. Er ist zustandslos und Clients sollten keine Vorkenntnisse haben, um darüber hinaus mit dem Server zu interagieren das Verständnis von Hypermedien.

16
marvelTracker

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 Operationen, komplexen Typen usw. definiert. SOAP ist ausgerichtet zu Operationen, aber REST orientiert sich an 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.

enter image description here

Zunächst einmal: Offiziell wäre die richtige Frage web services + WSDL + SOAP vs REST.

Denn obwohl der Webdienst im losen Sinne verwendet wird, werden bei Verwendung des HTTP-Protokolls Daten anstelle von Webseiten übertragen , offiziell es ist eine sehr spezifische Form dieser Idee. Laut Definition ist REST kein "Web-Service".

In der Praxis ignoriert dies jedoch jeder. Lassen Sie es uns auch ignorieren

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 Remote Procedure Call/RPC bezeichnet). Angenommen, diese Funktion befindet sich unter einer bestimmten URL, die von der Person bereitgestellt wird, die sie geschrieben hat. Sie müssen ihm (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 Botschaft hin und her getragen werden?

Für die erste Frage lautet die offizielle Definition WSDL . Dies ist eine XML-Datei, die im detaillierten und strengen Format beschreibt, welche Parameter, welche Typen, Namen, Standardwerte, den Namen der aufzurufenden Funktion usw. verwendet werden. Ein Beispiel für WSDL Hier wird gezeigt, dass die Datei für Menschen lesbar ist (aber nicht einfach).

Für die zweite Frage gibt es verschiedene Antworten. In der Praxis wird jedoch nur SOAP verwendet. Die Hauptidee ist, das vorherige XML (die eigentliche Nachricht) in ein weiteres XML (mit Codierungsinformationen und anderen hilfreichen Informationen) zu verpacken und über HTTP zu senden. Die Methode POST des HTTP wird zum Senden der Nachricht verwendet, da immer ein Body vorhanden ist.

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

  • myapp/read-customer und übergeben Sie im Nachrichtentext die ID des Kunden, der gelesen werden soll.
  • myapp/update-customer und im Körper die ID des Kunden sowie die neuen Daten übergeben
  • 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 (aufgerufene Ressource im REST lingo). 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 die Kundennummer 12 unter der URL myapp/customers/12 gefunden. Um die Kundendaten anzuzeigen, drücken Sie die URL mit einer GET-Anfrage. Um es zu löschen, dieselbe URL mit einem DELETE-Verb. Um es zu aktualisieren, erneut dieselbe URL mit einem POST-Verb und dem neuen Inhalt im Anforderungshauptteil.

Weitere Informationen zu den Anforderungen, die ein Service erfüllen muss, um als wirklich REST-konform zu gelten, finden Sie im Richardson-Reifegradmodell . Der Artikel enthält Beispiele und erläutert, was noch wichtiger ist, warum ein (sogenannter) SOAP -Dienst ein REST -Dienst der Stufe 0 ist (obwohl Stufe 0 eine geringe Einhaltung von bedeutet) Dieses Modell ist nicht anstößig und in vielen Fällen immer noch nützlich.

10
blue_note

Ergänzung für:

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

++ 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 hebt die Dinge und Substantive hervor, aus denen eine Anwendung besteht.

7
Quan Nguyen

Viele dieser Antworten haben völlig vergessen, Hypermedia-Controls (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.

6
Phil Sturgeon