Was sind die entscheidenden Faktoren für die Bereitstellung eines Webdienstes als SOAP- oder REST-Dienst?

30

Soweit ich sehe, erfordert das Konsumieren von SOAP einen SOAP-Stack, so dass es für Ihre Kunden schwieriger ist, zu konsumieren, dh sie müssen sicherstellen, dass sie einen SOAP-Stack haben, der die POST-Daten und die Header korrekt formatiert und Ihnen dann einige zurückgibt Datenstruktur, während Sie mit REST nur eine HTTP-GET-Anforderung mit den Argumenten in der Abfragezeichenfolge ausführen und Text zurückerhalten, von dem ich denke, dass er wahrscheinlich XML ist.

Was bringt Ihnen der zusätzliche Overhead / die zusätzliche Komplexität von SOAP, wann brauchen Sie das und wann könnten und sollten Sie darauf verzichten?

web-services rest soap

17

Ich habe zuvor eine REST-API implementiert und es hat mir sehr gut gefallen. Wenn Sie REST über SOAP implementieren , ist Ihr Client / Server im Allgemeinen orthogonaler, was bedeutet, dass Sie den Server wesentlich freier ändern können, ohne dass dies Auswirkungen auf Ihre Clients hat. Diese Orthogonalität beruht auf der Verwendung einer abstrakteren und bereits genau definierten Kommunikation über HTTP-Verben. Durch die Verwendung von in Ihre REST-Antworten eingebetteten Hyperlinks ist es außerdem einfacher, Ihre API relativ schmerzfrei zu erweitern und zu erweitern. Kunden sollten diesen eingebetteten Links folgen, um zu neuen Ressourcen zu gelangen, so wie ein Mensch Links auf einer Webseite folgt, um weitere Informationen zu erhalten.

Nachdem dies gesagt war, hatte ich einige Kollegen, denen gesagt wurde, sie müssten SOAP verwenden und sie beschwerten sich die ganze Zeit darüber. Also habe ich mich etwas eingehender mit den beiden befasst.

Im Allgemeinen stellte ich fest, dass REST für stark verteilte Anwendungen mit Hunderten, Tausenden oder Millionen von Clients gut geeignet ist . Ein Grund ist die oben erwähnte Orthogonalität, ein anderer ist das Caching, das Sie kostenlos erhalten, da Sie HTTP verwenden.

SOAP ist möglicherweise der schnellste Weg, wenn Sie schnell eine kleinere API für einen oder zwei Clients benötigen und sich keine Sorgen über die Skalierbarkeit machen. Es passt möglicherweise auch besser zu Ihnen, wenn Sie nicht über eine ressourcenorientierte Architektur verfügen , da Sie möglicherweise einige Zeit benötigen, um Ihre App zu restrukturieren und sogar REST implementieren zu können.

— c_maker
quelle

2

Sie werden aufgrund des Ressourcenparadigmas und des Zustandsmangels zwischengespeichert, nicht aufgrund von HTTP.

— Dietbuddha

@dietbuddha HTTP gibt Ihnen die Implementierung kostenlos.

— Jacob Raihle

17

Es mag ein kleiner Punkt sein, aber REST basiert vollständig auf HTTP.

SOAP erfordert kein HTTP, und Sie können jeden beliebigen Transport verwenden.

SOAP-Nachrichten können asynchron und zuverlässig weitergeleitet werden, wohingegen REST so ziemlich ein synchrones Paradigma ist.

REST sagt Ihnen nichts darüber aus, wie die Daten, die Sie senden und empfangen, aussehen sollen. Es gibt WADL, aber meistens verlassen Sie sich darauf, dass die Dokumentation der API korrekt ist. SOAP verfügt über eine Vielzahl von XML-Technologien, um Datenbeschreibungen weniger fehleranfällig zu machen. WSDL, Schema ...

Letztendlich erhalten Sie mit REST im Grunde ein auf HTTP basierendes Dateisystem. Wenn Ihr System in dieses Paradigma passt, ist es möglicherweise eine gute Wahl.

— Sylvanaar
quelle

+1 für die Erwähnung mehrerer Transporte. Wenn Sie wirklich ein transportunabhängiges Protokoll benötigen (das z. B. den Betrieb über SMTP oder ähnliches unterstützt), ist REST nicht verfügbar. Normalerweise ist HTTP jedoch gut genug ...

— sleske

6

Ich sehe nicht, wie REST an HTTP gebunden ist. Das ist Implementierungsdetail. Die meisten REST-Implementierungen gehen über HTTP, aber ich verstehe nicht, warum ich REST nicht über andere Protokolle wie FTP implementieren konnte.

— Edalorzo

REST beschränkt nicht die Kommunikation zu einem bestimmten Protokoll ref: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

— NMTOKEN

7

Was bringt Ihnen der zusätzliche Overhead / die zusätzliche Komplexität von SOAP, wann brauchen Sie das und wann könnten und sollten Sie darauf verzichten?

Der größte Unterschied zwischen den beiden besteht darin, dass angenommen wird, dass REST zustandslos ist, wohingegen SOAP dies nicht ist . In der Praxis implementieren viele REST-Implementierungen tatsächlich einen Zustand in der Sitzung über etwas wie OAuth.

Ein weiterer Unterschied ist, dass REST sehr "ressourcen-" oder substantivorientiert ist . Sie interagieren mit Ressourcen über CRUD-Operationen. Alles, was nicht zu diesem Paradigma passt, wird umständlich und umständlich.

SOAP ist dagegen nur ein RPC-Protokoll (Remote Procedure Call) . Es kommt nicht mit einem Paradigma, es ist nur die Transportschicht.

— dietbuddha
quelle

1

Sowohl SOAP als auch REST sind nur Mittel, um ein Endergebnis zu erzielen. Sie können für die Aufgabe geeignet sein oder auch nicht. So kann auch REST als Transportschicht gesehen werden. Sogar die Status- / Weniger-Ansicht hat keine Gültigkeit: Sie können beide Varianten sowohl mit APIs als auch mit anderen API-Typen entwerfen. Sie können sogar eine duale API haben, die sowohl einen SOAP- als auch einen REST-Endpunkt hat. Und ein XML-RPC-Endpunkt. Und ein Apache Thrift-Endpunkt. Und ein Endpunkt von Google Protocol Buffers. Und was noch. Am Ende des Tages ist alles nur ein RPC.

— JensG

4

REST verwendet auch die Post. Tatsächlich geben die http-Verben bei Verwendung von REST Auskunft darüber, welche Operation ausgeführt wird.

REST und SOAP sind unterschiedliche Standards für die Weitergabe von Daten über das Internet.

Wenn Sie beides verwendet haben, würde ich im Allgemeinen die Verwendung von REST anstelle von SOAP empfehlen, es sei denn, Sie wissen, dass die Benutzer, die Ihren Webdienst verwenden, .NET und Visual Studio verwenden. Es ist im Allgemeinen viel einfacher, einen REST-Webdienst zu nutzen, außer mit .net VS, das die meiste Arbeit für Sie erledigt, wenn Sie SOAP verwenden.

— Tom Squires
quelle

4

Auch in Java gibt es eine gute SOAP-Unterstützung.

4

Eine Sache, die ich erwähnen möchte, ist die Interoperabilität. Wenn Sie Ihren Service über eine in .NET geschriebene App aufrufen und der Server in Java (oder einer anderen Kombination) geschrieben ist, entscheiden Sie sich für REST. Ich habe zu viele leichte Inkompatibilitäten zwischen SOAP-Implementierungen festgestellt, als dass ich mir Gedanken darüber machen könnte.

— gbjbaanb
quelle

2

Zustimmen. SOAP ist ein Industriestandard, der jedoch zu komplex ist und zu Unmengen von fehlerhaften oder unvollständigen Implementierungen führt. Darüber hinaus weist SOAP im Vergleich zu anderen Ansätzen in der Regel den größten Platzbedarf in Bezug auf Leistung und Datenverkehr auf.

— JensG

1

Wenn Sie nur eine einfache visuelle Anleitung benötigen, mit der Sie SOAP und REST an Ihren Anwendungsanforderungen messen können ...

Vijay Prasad Gupta hat ein einfaches, hilfreiches Flussdiagramm zusammengestellt.

Direkter Link zum Ablaufdiagramm: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit

Link zum Artikel: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-zum-ermitteln-der- richtigen-Webservices- protokoll-für-Ihre- Bedürfnisse

— JTech
quelle

Das ist eigentlich ein ziemlich anständiges Flussdiagramm. Ich war überrascht, dass hier keine einzige Antwort die Vorteile von SOAP gegenüber REST anspricht. Das Flussdiagramm tut es jedoch. Ich denke, ich könnte das Flussdiagramm hier als Bild einfügen, anstatt es zu verknüpfen, nur um sicherzugehen, dass es bei der Antwort bleibt?

— 7.

-2

Es ist jetzt 2015. Ich hätte gehofft, dass SOAP inzwischen gestorben ist, aber es verweilt immer noch wie ein übler Geruch. Für alles andere als die grundlegendsten "Beispiel" -Anwendungen ist die Integration in einen SOAP-Dienst mit Herausforderungen verbunden. Es ist eine komplexe Architektur mit vielen Optionen auf mehreren Ebenen, kombiniert mit den Macken mehrerer Implementierungen und subtilen (und nicht so subtilen) Inkompatibilitäten. Ich habe noch nie eine gute Erfahrung damit gemacht. REST hingegen ist ein Kinderspiel: Jeder versteht HTTP. In den meisten Fällen hat JSON also muh mehr Nutzen als XML InfoSet.

Versuchen Sie, eine SOAP-Bibliothek in Ihr Projekt zu integrieren, um sich ein Bild von der Komplexität von SOAP zu machen. Für Java bezieht der grundlegendste Apache Axis2-Client (mit einfacher ADB-Datenbindung) 23 neue JARs. 23! 20 MB Bibliothek aufblähen. CXF ist ähnlich: 21 JARs, als ich zuletzt gezählt habe.

Wenn Sie es wirklich wollten, können Sie REST mit einer einfachen HTTP-Bibliothek ausführen.

— Cornel Masson
quelle

1

Das liest sich eher wie ein Geschwätz, siehe Wie man antwortet

— Mücke

Du hast recht. Entschuldigung, ich war zu der Zeit

— Cornel Masson

1

Wir hatten die gleiche Beschwerde mit CORBA / IDL in den 90er Jahren. Dann plötzlich "Simple Object Access Protocol" ... wird es einfach! Es wird cool sein! Es wird schnell gehen. Zehn Jahre später gilt es als zu komplex. Es folgen JSON (IMAO ist wirklich ein rechteckiges Rad für Datenübertragungsvorgänge in Schülerlaboreinstellungen oder eingeschränkte "Ich weiß, was ich tue" -Situationen zur schnellen Fehlerbehebung) und RESTful Ops. Spülen, wiederholen ...

— David Tonhofer

Ich fürchte, jede wahre Aussage über SOAP muss als Schimpfwort gelesen werden. Es ist von Natur aus unternehmerisch und bietet Ihnen eine Vielzahl von Optionen, mit denen Sie nur einige Daten senden möchten. In Bezug auf die wenigen SOAP-Schnittstellen, mit denen ich gearbeitet habe, war jede ein hochgradig redundantes Durcheinander (nicht gerade SOAPs Fehler, aber die Affinität zu SOAP korreliert mit der Affinität zu Bloatware). Entschuldigung für das Geschimpfe.

— Maaartinus