it-swarm-eu.dev

SOAP oder REST für Web Services?

Ist REST ein besserer Ansatz für die Ausführung von Webdiensten oder ist es SOAP? Oder sind es unterschiedliche Tools für unterschiedliche Probleme? Oder ist es ein nuanciertes Problem - das heißt, eines ist in bestimmten Bereichen etwas besser als das andere , usw?

Ich würde mich besonders über Informationen zu diesen Konzepten und deren Beziehung zum PHP-Universum sowie zu modernen High-End-Webanwendungen freuen.

380
user13276

Ich habe einen der ersten SOAP Server, einschließlich Code-Generierung und WSDL-Generierung, aus der ursprünglichen Spezifikation gebaut, als ich bei Hewlett-Packard arbeitete. Ich empfehle NICHT, = zu verwenden SOAP für alles.

Das Akronym "SOAP" ist eine Lüge. Es ist nicht einfach, es ist nicht objektorientiert, es definiert keine Zugriffsregeln. Es ist wohl ein Protokoll. Es ist die schlechteste Spezifikation von Don Box, und das ist eine ziemliche Leistung, da er der Mann ist, der "COM" begangen hat.

Es gibt nichts Nützliches in SOAP, das nicht mit REST für den Transport und JSON, XML oder sogar Klartext für die Datendarstellung möglich ist. Für den Transport Für die Sicherheit können Sie https verwenden. Für die Authentifizierung die grundlegende Authentifizierung. Für Sitzungen gibt es Cookies. Die REST Version wird einfacher, übersichtlicher, schneller ausgeführt und benötigt weniger Bandbreite.

XML-RPC definiert die Anforderungs-, Antwort- und Fehlerprotokolle klar und es gibt gute Bibliotheken für die meisten Sprachen. XML ist jedoch schwerer als für viele Aufgaben erforderlich.

562
mdhughes

REST ist eine Architektur, SOAP ist ein Protokoll.

Das ist das erste Problem.

Sie können SOAP Umschläge in einer REST Anwendung senden.

SOAP selbst ist eigentlich ziemlich einfach und es sind die WSS- * -Standards, die es sehr komplex machen.

Wenn Ihre Kunden andere Anwendungen und andere Server sind, wird das SOAP) -Protokoll heutzutage in großem Umfang unterstützt, und die Grundlagen für das Verschieben von Daten sind in modernen IDEs im Wesentlichen ein Mausklick.

Wenn Ihre Kunden mit größerer Wahrscheinlichkeit RIAs oder Ajax-Clients sind, möchten Sie wahrscheinlich etwas Einfacheres als SOAP und für den Client natürlicheres (insbesondere JSON).

Über HTTP gesendete JSON-Pakete sind nicht unbedingt eine REST Architektur, sondern nur Nachrichten an URLs. Alle funktionieren einwandfrei, aber das REST Idiom enthält Schlüsselkomponenten. Es ist jedoch leicht, die beiden zu verwechseln. Nur weil Sie über HTTP-Anforderungen sprechen, bedeutet dies nicht unbedingt, dass Sie eine REST Architektur haben. Sie können eine REST = Anwendung ohne HTTP (Achtung, dies ist selten).

Wenn Sie also Server und Konsumenten haben, die mit SOAP "vertraut" sind, können SOAP und WSS Stack Ihnen gute Dienste leisten. Wenn Sie mehr Ad-hoc-Aufgaben erledigen und eine bessere Schnittstelle mit dem Web herstellen möchten Browser, dann kann ein etwas leichteres Protokoll über HTTP auch gut funktionieren.

198
Will Hartung

REST ist ein grundlegend anderes Paradigma als SOAP. Eine gute Lektüre zu REST kann hier gefunden werden: Wie ich REST zu meiner Frau erklärt habe .

Wenn Sie keine Zeit zum Lesen haben, finden Sie hier die Kurzfassung: REST ist ein kleiner Paradigmenwechsel, indem Sie sich auf "Nomen" konzentrieren und die Anzahl der "Verben", die Sie können, begrenzen gelten für diese Nomen. Die einzigen zulässigen Verben sind "get", "put", "post" und "delete". Dies unterscheidet sich von SOAP, wobei viele verschiedene Verben auf viele verschiedene Nomen angewendet werden können (dh viele verschiedene Funktionen).

Bei REST werden die vier Verben den entsprechenden HTTP-Anforderungen zugeordnet, während die Substantive durch URLs identifiziert werden. Dadurch wird die Statusverwaltung viel transparenter als in SOAP, wo häufig nicht klar ist, welcher Status auf dem Server und welcher auf dem Client vorhanden ist.

In der Praxis entfällt das meiste davon, und REST bezieht sich normalerweise nur auf einfache HTTP-Anforderungen, die zu JSON führen. while SOAP ist eine komplexere API, die über die Weitergabe von XML kommuniziert. Beide haben ihre Vor- und Nachteile, aber ich habe festgestellt, dass es nach meiner Erfahrung REST ist In der Regel die bessere Wahl, da Sie selten oder nie die volle Funktionalität von SOAP benötigen.

102
toluju

Kurzer Überblick über die Frage 2012:

Bereiche, in denen REST sehr gut funktioniert, sind:

  • Begrenzte Bandbreite und Ressourcen. Denken Sie daran, dass die Rückgabestruktur wirklich in jedem Format vorliegt (vom Entwickler definiert). Außerdem kann jeder Browser verwendet werden, da der REST Ansatz die Standardverben GET, PUT, POST und DELETE verwendet. Denken Sie auch hier daran, dass REST ebenfalls verwendet werden kann das XMLHttpRequest-Objekt, das die meisten modernen Browser heute unterstützen und das einen zusätzlichen Bonus von AJAX bietet.

  • Völlig zustandslose Operationen. Wenn eine Operation fortgesetzt werden muss, ist REST nicht der beste Ansatz und SOAP passt möglicherweise besser dazu. Wenn Sie jedoch zustandslose CRUD-Operationen (Erstellen, Lesen, Aktualisieren und Löschen) benötigen, dann ist es REST).

  • Zwischenspeichern von Situationen Wenn die Informationen aufgrund der völlig zustandslosen Operation des REST Ansatzes zwischengespeichert werden können, ist dies perfekt Das deckt viele Lösungen in den oben genannten drei ab.

Warum sollte ich SOAP überhaupt in Betracht ziehen? Auch hier ist SOAP ziemlich ausgereift und gut definiert und wird mit einer vollständigen Spezifikation geliefert. Der REST Ansatz ist genau das, ein Ansatz und weit offen für Wenn Sie also folgendes haben, ist SOAP eine großartige Lösung:

  • Asynchrone Verarbeitung und Aufruf. Wenn Ihre Anwendung ein garantiertes Maß an Zuverlässigkeit und Sicherheit benötigt, bietet SOAP 1.2 zusätzliche Standards an Stellen Sie diese Art von Operation sicher: WSRM - WS-Reliable Messaging.

  • Formelle Verträge. Müssen sich beide Seiten (Anbieter und Verbraucher) auf das Austauschformat einigen, dann gibt SOAP 1.2 das starre Vorgaben für diese Art der Interaktion.

  • Stateful Operations. Wenn die Anwendung Kontextinformationen und Konversationszustandsverwaltung benötigt, hat SOAP 1.2 die zusätzliche Spezifikation im WS * Struktur, um diese Dinge zu unterstützen (Sicherheit, Transaktionen, Koordination, etc.). Im Vergleich dazu würde der REST Ansatz die Entwickler veranlassen, dieses benutzerdefinierte Sanitär zu bauen.

http://www.infoq.com/articles/rest-soap-when-to-use-each

59
PmanAce

SOAP hat derzeit den Vorteil besserer Tools, mit denen ein Großteil des Code sowohl für die Serviceebene als auch für die Generierung von Clients aus einer bestimmten WSDL generiert wird.

REST ist einfacher, kann daher einfacher zu warten sein, liegt im Zentrum der Webarchitektur, ermöglicht eine bessere Protokollsichtbarkeit und hat sich als skalierbar erwiesen an der Größe des WWW selbst. Einige Frameworks unterstützen Sie beim Erstellen von REST Diensten, wie Ruby auf Rails, und einige unterstützen Sie sogar beim Schreiben von Clients, wie ADO.NET Data Services Zum größten Teil fehlt die Werkzeugunterstützung.

44
Mark Cidade

SOAP ist aus Tooling-Sicht nützlich, da die WSDL so leicht von Tools verwendet werden kann. So können Sie Web-Service-Clients in Ihrer bevorzugten Sprache für Sie generieren lassen.

REST funktioniert gut mit AJAX'y-Webseiten. Wenn Sie Ihre Anforderungen einfach halten, können Sie Serviceabrufe direkt von Ihrem JavaScript aus tätigen, und das ist sehr praktisch. Versuchen Sie, sich von Namespaces in Ihrem Antwort-XML fernzuhalten. Ich habe Browser gesehen, die an diesen erstickt sind. Also, xsi: type wird wahrscheinlich nicht für Sie funktionieren, keine übermäßig komplexen XML-Schemata.

REST weist tendenziell auch eine bessere Leistung auf. Die CPU-Anforderungen des Codes, der REST Antworten generiert, sind in der Regel niedriger als das, was SOAP Frameworks aufweisen. Und wenn Sie Ihre XML-Generierungs-Enten auf dem Server ausgerichtet haben Stellen Sie sich vor, Sie lesen Zeilen des Datenbankcursors. Wenn Sie eine Zeile lesen, formatieren Sie sie als XML-Element und schreiben sie direkt an den Service-Consumer Auf diese Weise müssen Sie nicht alle Datenbankzeilen im Speicher sammeln, bevor Sie mit dem Schreiben Ihrer XML-Ausgabe beginnen - Sie lesen und schreiben gleichzeitig. Schauen Sie sich neuartige Templating-Engines oder XSLT an, damit das Streaming für REST funktioniert.

SOAP hingegen wird von toolgenerierten Diensten in der Regel als großer Blob generiert und erst dann geschrieben. Dies ist keine absolute Wahrheit, wohlgemerkt, es gibt Möglichkeiten, Streaming-Eigenschaften aus SOAP herauszuholen, beispielsweise durch die Verwendung von Anhängen.

Mein Entscheidungsprozess sieht wie folgt aus: Wenn ich möchte, dass mein Service von Verbrauchern problemlos bearbeitet wird und die von mir geschriebenen Nachrichten mittelgroß bis klein (10 MB oder weniger) sind und es mir nichts ausmacht, eine zusätzliche CPU zu verbrauchen zyklen auf dem server gehe ich mit soap. Wenn ich AJAX auf Webbrowsern dienen muss, oder wenn ich das Ding zum Streamen brauche oder meine Antworten gigantisch sind, gehe ich auf REST.

Schließlich gibt es viele großartige Standards rund um SOAP, wie WS-Security und Stateful Web Services, an die Sie sich anschließen können, wenn Sie die richtigen Tools verwenden. Diese Art von Sachen macht wirklich einen Unterschied und kann Ihnen helfen, einige haarige Anforderungen zu erfüllen.

40
Dave Woldrich

Ich weiß, dass dies eine alte Frage ist, aber ich muss meine Antwort posten - vielleicht findet es jemand nützlich. Ich kann nicht glauben, wie viele Leute REST über SOAP empfehlen. Ich kann nur davon ausgehen, dass diese Leute keine Entwickler sind oder noch nie einen REST) - Service implementiert haben jede vernünftige Größe. Das Implementieren eines REST - Dienstes dauert viel länger als das Implementieren eines SOAP - Dienstes. Und am Ende wird es auch viel unordentlicher Sind die Gründe, warum ich SOAP 99% der Zeit wählen würde:

1) Das Implementieren eines REST Service dauert unendlich länger als das Implementieren eines SOAP Service. Es gibt Tools für alle modernen Sprachen/Frameworks/Plattformen, um eine WSDL einzulesen und auszugeben Proxy-Klassen und -Clients. Die Implementierung eines REST) - Dienstes erfolgt von Hand und - erhalten Sie dies - durch Lesen der Dokumentation. Außerdem müssen Sie bei der Implementierung dieser beiden Dienste "Vermutungen" anstellen, was geschehen soll Komm zurück über die Pipe, da es kein echtes Schema oder Referenzdokument gibt.

2) Warum einen REST Service schreiben, der trotzdem XML zurückgibt? Der einzige Unterschied ist, dass Sie mit REST nicht wissen, welche Typen jedes Element/Attribut repräsentiert - Sie müssen es selbst implementieren und hoffen, dass eines Tages ein String in einem Feld, von dem Sie dachten, dass es immer ein Int war, nicht vorkommt. SOAP definiert die Datenstruktur mithilfe der WSDL keine harte Nuss.

3) Ich habe die Beschwerde gehört, dass mit SOAP Sie den "Overhead" der SOAP Envelope haben. In der heutigen Zeit brauchen wir das wirklich sich Sorgen um eine Handvoll Bytes machen?

4) Ich habe das Argument gehört, dass Sie mit REST) einfach die URL in den Browser einfügen und die Daten sehen können. Sicher, wenn Ihr REST) Dienst ist Verwenden einer einfachen oder keiner Authentifizierung Der Netflix-Dienst verwendet beispielsweise OAuth, wodurch Sie Dinge signieren und verschlüsseln müssen, bevor Sie Ihre Anfrage absenden können.

5) Warum benötigen wir für jede Ressource eine "lesbare" URL? Wenn wir zur Implementierung des Dienstes ein Tool verwenden, interessiert uns dann die tatsächliche URL wirklich?

Muss ich weitermachen?

29
Josh M.

Die meisten Anwendungen, die ich schreibe, sind serverseitige C # - oder Java-Anwendungen oder Desktopanwendungen in WinForms oder WPF. Diese Anwendungen benötigen in der Regel eine umfangreichere Service-API als von REST= zur Verfügung gestellt werden kann. Außerdem möchte ich nicht länger als ein paar Minuten damit verbringen, meinen Web-Service-Client zu erstellen. Die Generierungstools für WSDL-Verarbeitungsclients Gestatten Sie mir, meinen Kunden zu implementieren und den Geschäftswert zu steigern.

Wenn ich einen Webdienst explizit für einige Javascript-Ajax-Aufrufe schreibe, würde er wahrscheinlich in REST sein. Nur um die Client-Technologie zu kennen und JSON zu nutzen. Meiner Meinung nach sollten Web-Service-APIs, die mit Javascript verwendet werden, wahrscheinlich nicht sehr komplex sein, da diese Komplexität auf der Serverseite anscheinend besser gehandhabt wird.

Nachdem dies gesagt wurde, gibt es einige SOAP Clients für Javascript; ich weiß, dass jQuery einen hat. Also SOAP kann Nutzung von Javascript; Nur nicht so gut wie ein REST Service, der JSON-Strings zurückgibt. Wenn ich also einen Web-Service hätte, der so komplex sein soll, dass er für eine beliebige Anzahl von Client-Technologien und -Verwendungen flexibel ist, würde ich würde mit SOAP gehen.

19
Travis Heseman

Ich würde empfehlen, zuerst REST zu verwenden - wenn Sie Java verwenden, schauen Sie sich JAX-RS und die Jersey -Implementierung an . REST ist in vielen Sprachen viel einfacher und einfacher zu bedienen.

Wie andere in diesem Thread gesagt haben, ist das Problem mit SOAP) die Komplexität, wenn die anderen WS- * -Spezifikationen eingehen, und es gibt unzählige Interop-Probleme, wenn Sie sich in die falschen Teile von WSDL, XSDs verirren , SOAP, WS-Adressierung etc.

Der beste Weg, um die REST v SOAP) - Debatte zu beurteilen, ist das Betrachten im Internet - so ziemlich alle großen Player im Webspace, Google, Amazon, eBay , Twitter et al. Verwenden und bevorzugen RESTful - APIs gegenüber den SOAP.

Der andere gute Ansatz für REST ist, dass Sie viel Code und Infrastruktur zwischen einer Webanwendung und einem REST= Frontend wiederverwenden können, z. B. das Rendern von HTML versus XML und JSON Ihrer Ressourcen sind normalerweise mit Frameworks wie JAX-RS und impliziten Ansichten recht einfach zu handhaben. Außerdem ist es einfach, mit RESTful-Ressourcen über einen Webbrowser zu arbeiten

17
James Strachan

Ich bin mir sicher, dass Don Box SOAP als Scherz - 'Sieh mal kann RPC-Methoden über das Web aufrufen' erstellt hat und heute stöhnt, als er merkt, wovon ein aufgeblähter Albtraum ist Webstandards ist es geworden :-)

REST ist gut, einfach, überall schnell und einfach zu implementieren (also eher ein "Standard" als die Standards). Verwenden Sie REST.

16
gbjbaanb

Ich denke, dass beide ihren eigenen Platz haben. Meiner Meinung nach:

SOAP : Eine bessere Wahl für die Integration zwischen älteren/kritischen Systemen und einem Web/Web-Service-System auf der Basisebene, auf der WS- * sinnvoll ist ( Sicherheit, Politik usw.).

RESTful: Eine bessere Wahl für die Integration von Websites mit öffentlicher API auf der obersten Ebene (VIEW, dh Javascripts, die Aufrufe an URIs entgegennehmen).

15
irobson

Eine Sache, die nicht erwähnt wurde, ist, dass ein SOAP) - Umschlag sowohl Header als auch Körperteile enthalten kann. Auf diese Weise können Sie die volle Ausdruckskraft von XML zum Senden und Empfangen von Out-of-Band-Informationen nutzen. REST Soweit ich weiß, sind Sie auf HTTP-Header und Ergebniscodes beschränkt.

(Können Sie auch Cookies mit einem REST Service verwenden, um Out-of-Band-Daten vom Typ "Header" zu senden?)

13
John Saunders

Beantwortung der 2012 aktualisierten Frage (durch die zweite Prämie) und Überprüfung der heutigen Ergebnisse (andere Antworten).


SOAP, Pro und Contra

Über SOAP 1.2, Vor- und Nachteile im Vergleich zu "REST" ... Nun, seit 2007 können Sie REST Webdienste mit WSDL beschreiben , und mit SOAP Protokoll ... Das heißt, wenn Sie etwas härter arbeiten,alle W3C-Standards des Web-Services-Protokollstacks kann RESTsein!

Dies ist ein guter Ausgangspunkt, da wir uns ein Szenario vorstellen können, in dem alle philosophischen und methodischen Diskussionen vorübergehend vermieden werden. Wir können technisch "SOAP-REST" mit "NON-SOAP-REST" in ähnlichen Diensten vergleichen,

  • SOAP-REST(= "REST-SOAP"): Wie von L.Mandel gezeigt , kann WSDL2 a REST Webservice, und wenn wir annehmen, dass beispielhaftes XML in SOAP eingeschlossen werden kann, lautet die gesamte Implementierung "SOAP-REST".

  • NON-SOAP-REST: any REST Webdienst, der nicht SOAP sein kann ... Das sind "90%" der bekannten REST Beispiele. Einige verwenden kein XML (z. B. Typical AJAX RESTs verwenden stattdessen JSON), andere verwenden andere XML-Strukturen ohne die SOAP -Header oder -Regeln. PS: Um Informalität zu vermeiden, können wir in den Vergleichen REST Level 2 annehmen.

Um konzeptioneller zu vergleichen, vergleichen Sie natürlich "NON-REST-SOAP" mit "NON-SOAP-REST" als unterschiedliche Modellierungsansätze. Vervollständigen Sie also diese Taxonomie von Webdiensten:

  • NON-REST-SOAP: any SOAP Webdienst, der nicht REST sein kann ... Das sind "90%" der bekannten SOAP Beispiele.

  • NON-REST-NEITHER-SOAP: ja, das Universum der "Webservices-Modellierung" umfasst andere Dinge (zB XML-RPC ).

SOAP in den REST Bedingungen

Vergleiche vergleichbare Dinge: SOAP-REST mit NON-SOAP-REST .

PROS

Einige Begriffe zu erklären,

  • Vertragsstabilität : für alle Arten von Verträgen (als "schriftliche Vereinbarungen"),

    • Durch die Verwendung von Standards : Alle Ebenen des W3C-Stacks sind miteinander kompatibel. REST hingegen ist kein W3C- oder ISO-Standard und enthält keine normierten Details zu den Peripheriegeräten des Dienstes. Also, als I , @DaveWoldrich (20 Stimmen), @cynicalman (5), @Exitos (0) sagte, in einem Kontext, wo sind BENÖTIGEN SIE FÜR NORMEN, benötigen Sie SEIFE.

    • Durch die Verwendung von Best Practices : Der "ausführliche Aspekt" der W3C-Stack -Implementierungen übersetzt relevante menschliche/rechtliche/juristische Vereinbarungen.

  • Robustheit : die Sicherheit von SOAP Struktur und Headern. Mit metada communication (mit der vollen Aussagekraft von XML) und verification haben Sie eine "Versicherung" gegen Änderungen oder Lärm.
    SOAP verfügt über "Transaktionszuverlässigkeit (...) bei Kommunikationsfehlern. SOAP verfügt über mehr Steuerungsmöglichkeiten für die Wiederholungslogik und kann somit mehr End-to-End-Zuverlässigkeit und Servicegarantien bieten", E. Terman .

Pro nach Beliebtheit sortieren,

  • Bessere Tools(~ 70 Stimmen): SOAP hat derzeit den Vorteil von besseren Tools, seit 2007 und noch 2012, weil es ein gut definiertes ist und weithin akzeptierter Standard. Siehe @ MarkCidade (27 Stimmen), @ DaveWoldrich (20), @ JoshM (13), @ TravisHeseman (9).

  • Standardkonformität(25 Stimmen): als I , @DaveWoldrich (20 Stimmen), @cynicalman (5), @Exitos (0) sagte zuvor, in einem Kontext, in dem NORMEN NOTWENDIG sind, benötigen Sie SOAP.

  • Robustheit: Versicherung von SOAP Headern, @JohnSaunders (8 Stimmen).

CONS

  • SOAP-Struktur ist komplexer(mehr als 300 Stimmen): Alle Antworten hier und Quellen zu "SOAP vs REST" zeigen eine gewisse Abneigung gegen die Redundanz und Komplexität von SOAP. Dies ist eine natürliche Folge der Anforderungen an die formale Verifizierung (siehe unten) und an die Robustheit (siehe oben). "REST NON-SOAP" (und XML-RPC, der SOAP-Urheber ) können einfacher und informeller sein.

  • Die "einzige XML" -Einschränkung ist ein Leistungshindernisbei der Verwendung kleiner Dienste (~ 50 Stimmen): siehe json.org/xml und diese Frage oder diese andere . Dieser Punkt wird von @toluju (41) und anderen gezeigt.
    PS: as JSON ist kein IETF-Standard , aber wir können einen De-facto-Standard für die Web-Software-Community in Betracht ziehen.


Modellierungsdienste mit SOAP

Jetzt können wir SOAP-NON-REST mit NON-SOAP-REST -Vergleichen hinzufügen undwhen erklären ist besser, SOAP zu verwenden:

  • Bedarf an Standards und stabilen Verträgen (siehe Abschnitt "PROS"). PS: Siehe ein typisches "B2B-Bedürfnis nach Standards", beschrieben von @saille .

  • Benötigen Sie Werkzeuge (siehe Abschnitt "PROS"). PS: Standards und das Vorhandensein formaler Überprüfungen (siehe unten) sind wichtige Aspekte für die Automatisierung von Werkzeugen.

  • Parallel Heavy Processing (siehe Abschnitt "Kontext/Grundlagen" weiter unten): Bei größeren und/oder langsameren Prozessen, unabhängig von der Komplexität von SOAP, sind Zuverlässigkeit und Stabilität die besten Investitionen.

  • Benötigen Sie mehr Sicherheit : Wenn mehr als HTTPS erforderlich ist und Sie zusätzliche Schutzfunktionen benötigen, ist SOAP die bessere Wahl ( see @ Bell , 32 Stimmen). Msgstr "Senden der Nachricht entlang eines Pfades, der komplizierter ist als die Anforderung/Antwort oder über einen Transport ohne HTTP", S. Seely . XML ist ein zentrales Thema und bietet Standards für XML-Verschlüsselung , XML-Signatur und XML-Kanonisierung , nur mit SOAP können Sie diese Mechanismen nach einem allgemein akzeptierten Standard als WS-Security in eine Nachricht einbetten.

  • Benötigen Sie mehr Flexibilität (weniger Einschränkungen): SOAP Benötigen Sie keine exakte Korrespondenz mit einem URI; nicht auf HTTP beschränkt; nicht auf 4 Verben beschränken müssen. Wie @TravisHeseman (9 Stimmen) sagt, sollten Sie SOAP verwenden, wenn Sie etwas "Flexibles für eine beliebige Anzahl von Client-Technologien und -Verwendungen" möchten.
    PS: Denken Sie daran, dass XML universeller und aussagekräftiger ist als JSON (et al.).

  • Notwendigkeit von formalen Überprüfungen: Wichtig zu verstehen, dass der W3C-Stack formale Methoden verwendet , und REST sind informeller. Ihre WSDL-Dienstbeschreibung (eine formale Sprache ) ist eine formale Spezifikation Ihrer Webdienstschnittstellen, und SOAP ist ein robustes Protokoll, das Akzeptieren Sie alle möglichen WSDL-Vorschriften.

KONTEXT

Historisches

Zur Beurteilung von Trends ist eine historische Perspektive notwendig. Für dieses Thema eine Perspektive von 10 oder 15 Jahren ...

Vor der W3C-Standardisierung gab es eine gewisse Anarchie. Es war schwierig, interoperable Dienste mit unterschiedlichen Frameworks zu implementieren, und es war schwieriger, kostspieliger und zeitaufwendiger, etwas zu implementieren, das zwischen Unternehmen interoperabel ist. Die W3C-Stack-Standards waren ein Leichtes, ein Nördliches für das Zusammenspiel von Sätzen komplexer Webdienste.

Für alltägliche Aufgaben, wie die Implementierung von AJAX, ist SOAP sehr wichtig. Die Notwendigkeit einfacher Ansätze erfordert die Wahl eines neuen Theorie-Frameworks. Und große "Web-Software-Player". Als beste Alternative haben Google, Amazon, Yahoo ua REST gewählt. War in diesem Zusammenhang das REST Konzept als "konkurrierendes Framework" angekommen, und heute (2012) ist diese Alternative ein de facto Standard für Programmierer.

Stiftungen

In einem Kontext von Parallel Computing stellen die Webdienste parallele Unteraufgaben bereit. und Protokolle wie SOAP gewährleisten eine gute Synchronisation und Kommunikation. Keine "beliebige Aufgabe": Webservices können als klassifiziert werden
grobkörnige und peinliche Parallelität .

Je größer die Aufgabe wird, desto weniger wird die "Komplexitätsdebatte" und desto relevanter werden die Robustheit der Kommunikation und die Solidität der Verträge.

10
Peter Krauss

Übersehen Sie nicht XML-RPC. Wenn Sie sich nur für eine einfache Lösung interessieren, gibt es eine Menge zu sagen für ein Protokoll, das in ein paar Textseiten definiert und mit einer minimalen Menge an Code implementiert werden kann. XML-RPC gibt es schon seit Jahren, aber es ist eine Weile aus der Mode gekommen - aber der minimalistische Reiz scheint es in letzter Zeit etwas wiederzubeleben.

10
Cruachan

Es ist nuanciert.

Wenn Sie eine andere Systemschnittstelle zu Ihren Diensten benötigen, sind viele Clients mit SOAP zufriedener, da die Verträge, WSDL und SOAP = Standard.

Für alltägliche Systeme, die Systeme aufrufen, halte ich SOAP für eine Menge unnötigen Overhead, wenn ein einfacher HTML-Aufruf ausreicht.

9
cynicalman

Ich schaue auf das gleiche, und ich denke, sie sind verschiedene Werkzeuge für verschiedene Probleme.

Der SOAP-Standard (Simple Object Access Protocol), eine XML-Sprache, die eine Nachrichtenarchitektur und Nachrichtenformate definiert, wird von Webdiensten verwendet und enthält eine Beschreibung der Vorgänge. WSDL ist eine XML-basierte Sprache zur Beschreibung von Webdiensten und zum Zugriff darauf. Läuft auf SMTP, HTTP, FTP usw. Benötigt Middleware-Unterstützung, gut definierte Mechanismen zum Definieren von Diensten wie WSDL + XSD, WS-Policy SOAP gibt XML-basierte Daten zurück SOAP bietet Standards für Sicherheit und Zuverlässigkeit

REST-Webdienste (Representational State Transfer). Sie sind Web Services der zweiten Generation. RESTful-Webdienste kommunizieren über HTTP als SOAP-basierte Dienste und erfordern keine XML-Nachrichten oder WSDL-Service-API-Definitionen. Für REST ist keine Middleware erforderlich. Nur HTTP-Unterstützung ist erforderlich. WADL-Standard, REST kann XML, Nur-Text, JSON, HTML usw. zurückgeben

Für viele Arten von Clients ist es einfacher, REST-konforme Webdienste zu nutzen, während sich die Serverseite weiterentwickeln und skalieren kann. Kunden können einige oder alle Aspekte des Dienstes nutzen und mit anderen webbasierten Diensten kombinieren.

  1. REST verwendet Standard-HTTP, sodass es einfacher ist, Clients zu erstellen und APIs zu entwickeln
  2. REST erlaubt viele verschiedene Datenformate wie XML, Nur-Text, JSON, HTML, wobei SOAP nur XML erlaubt.
  3. REST bietet eine bessere Leistung und Skalierbarkeit.
  4. Ruhe und kann zwischengespeichert werden und SOAP kann nicht
  5. Eingebaute Fehlerbehandlung, bei der SOAP keine Fehlerbehandlung hat
  6. REST ist besonders nützlich PDA und andere mobile Geräte.

REST ist, dass Services einfach in bestehende Websites integriert werden können.

SOAP verfügt über eine Reihe von Protokollen, die unter anderem Standards für Sicherheit und Zuverlässigkeit bieten und mit anderen WS-konformen Clients und Servern zusammenarbeiten. SOAP Webdienste (wie JAX-WS) sind nützlich für die asynchrone Verarbeitung und den asynchronen Aufruf.

Für komplexe APIs ist SOAP nützlicher.

9
kapil das

REST ist eine von Roy Fielding erfundene Architektur, die in seiner Dissertation Architekturstile und Entwurf netzwerkbasierter Softwarearchitekturen beschrieben wurde. Roy ist auch der Hauptautor von HTTP - dem Protokoll, das die Übertragung von Dokumenten über das World Wide Web definiert. HTTP ist ein REST-Protokoll. Wenn Entwickler von "Using REST Web Services" sprechen, ist es wahrscheinlich genauer, "Using HTTP" zu sagen.

SOAP ist ein XML-basiertes Protokoll, das innerhalb einer HTTP-Anfrage/Antwort getunnelt wird. Selbst wenn Sie SOAP verwenden, verwenden Sie also REST. Es gibt einige Debatten darüber, ob SOAP erweitert das grundlegende HTTP um wichtige Funktionen.

Vor dem Verfassen eines Webdienstes würde ich empfehlen, HTTP zu studieren. Wahrscheinlich können Ihre Anforderungen mit Funktionen implementiert werden, die bereits in der Spezifikation definiert sind, sodass keine anderen Protokolle erforderlich sind.

8
Chris Broski

Ich betrachte das gleiche Problem. Scheint mir, dass tatsächlich REST ist schnell und einfach und gut für einfache Anrufe und Antworten und großartig für das Debuggen (was könnte besser sein, als eine URL in einen Browser zu pumpen und die Antwort zu sehen).

Wo jedoch REST zu fallen scheint, hängt mit der Tatsache zusammen, dass es sich nicht um einen Standard handelt (obwohl er aus Standards besteht). Die meisten Programmierbibliotheken haben die Möglichkeit, eine WSDL zu inspizieren, um die WSDL automatisch zu generieren Client-Code, der benötigt wird, um SOAP basierte Dienste zu nutzen. Bisher verbrauchte REST basierte Web-Dienste scheinen ein adhocer Ansatz zu sein, eine Schnittstelle zu schreiben, die den Aufrufen entspricht, die es gibt Erstellen Sie eine manuelle http-Anforderung und analysieren Sie die Antwort. Dies kann an sich gefährlich sein.

Das Schöne an SOAP ist, dass Unternehmen, sobald eine WSDL ausgestellt wurde, ihre Logik so strukturieren können, dass Vertragsänderungen an der Schnittstelle die WSDL ändern. Es gibt keinen Handlungsspielraum Überprüfen Sie alle Anforderungen anhand dieser WSDL. Da eine WSDL einen REST Service nicht ordnungsgemäß beschreibt, haben Sie keine definierte Möglichkeit, die Schnittstelle für die Kommunikation zu vereinbaren.

Aus geschäftlicher Sicht lässt dies die Kommunikation offen für Interpretationen und Veränderungen, was eine schlechte Idee zu sein scheint.

Die obere 'Antwort' in diesem Thread scheint zu sagen, dass SOAP steht für Simple Object-Oriented Access Protocol, aber im Wiki bedeutet das O Object nicht Object-Oriented. Sie sind verschiedene Dinge.

Ich weiß, dass dieser Beitrag sehr alt ist, dachte aber, ich sollte mit meinen eigenen Erkenntnissen antworten.

7
Exitos

Es ist eine gute Frage ... Ich möchte Sie nicht in die Irre führen, also bin ich genauso offen für die Antworten anderer Menschen wie Sie. Für mich kommt es wirklich auf die Kosten des Overheads und die Verwendung der API an. Ich bevorzuge es, Webservices zu nutzen, wenn ich Client-Software erstelle, aber ich mag das Gewicht von SOAP nicht. Ich glaube, dass REST leichter ist, aber ich mag es aus Kundensicht nicht so sehr, damit zu arbeiten.

Ich bin gespannt, was andere denken.

6
cranley

Hören Sie diesen Podcast , um es herauszufinden. Wenn Sie die Antwort wissen möchten, ohne zuzuhören, dann OK, sein REST. Aber ich empfehle wirklich zuzuhören.

6
Mark Beckwith

Meine allgemeine Regel lautet: Wenn Sie möchten, dass ein Browser-Webclient eine direkte Verbindung zu einem Dienst herstellt, sollten Sie wahrscheinlich REST verwenden. Wenn Sie strukturierte Daten zwischen Back-End-Diensten übertragen möchten, verwenden Sie SOAP.

Das Einrichten von SOAP kann manchmal sehr mühsam sein und ist für den einfachen Datenaustausch zwischen Webclients und Servern oftmals zu teuer. Leider verstärken die meisten einfachen Programmierbeispiele, die ich gesehen habe (und aus denen ich gelernt habe), diese Wahrnehmung etwas.

Trotzdem ist SOAP wirklich eine gute Wahl, wenn Sie mehrere SOAP= Services als Teil eines größeren Prozesses kombinieren, der von einem Daten-Workflow gesteuert wird (denken Sie an Unternehmenssoftware) ist etwas, das viele der SOAP Programmierbeispiele nicht vermitteln, weil eine einfache SOAP) - Operation, um etwas zu tun, wie den Preis einer Aktie abzurufen, im Allgemeinen überkompliziert ist für das, was es selbst tut, es sei denn, es wird im Zusammenhang mit der Bereitstellung einer maschinenlesbaren API vorgestellt, die bestimmte Funktionen mit festgelegten Datenformaten für Ein- und Ausgaben detailliert, die wiederum von einem größeren Prozess skriptgesteuert werden.

Dies ist in gewisser Weise traurig, da es SOAP einen schlechten Ruf gibt, weil es schwierig ist, die Vorteile von SOAP zu zeigen, ohne es vollständig darzustellen Zusammenhang damit, wie das Endprodukt verwendet wird.

6
Rick Sarvas

Im Sinne von "PHP-Universum" PHP Unterstützung für fortgeschrittene SOAP saugt viel Zeit. Sie werden am Ende mit etwas wie http://wso2.com/products/web-services-framework/php/ sobald Sie die Grundbedürfnisse überschreiten, gibt es auch für WS-Security oder WS-RM keine eingebaute Unterstützung.

Ich finde, die Erstellung von SOAP-Umschlägen ist in PHP ziemlich chaotisch. Die Art und Weise, wie Namespaces erstellt werden, sind xsd: nil, xsd: anytype und altmodische Soap-Dienste, die SOAP Encoding) verwenden (Gott weiß, wie das anders ist) in SOAP Nachrichten.

Vermeiden Sie all dieses Durcheinander, indem Sie sich an REST halten. REST ist nichts wirklich Großes, das wir seit dem Start des WWW verwenden. Wir haben erst erkannt, wann dies http: //www.ics .uci.edu/~ fielding/pubs/dissertation/top.htm In diesem Artikel wird gezeigt, wie wir HTTP-Funktionen zum Implementieren von RESTFul-Diensten verwenden können RESTFul.

SOAP vernachlässigt die Kernfunktionen von HTTP und betrachtet HTTP nur als Transportprotokoll, daher ist es theoretisch unabhängig vom Transportprotokoll (in der Praxis ist dies nicht der Fall, von dem Sie schon einmal von SOAP Action Header gehört haben? Wenn nicht google es jetzt!).

Mit zunehmender JSON-Anpassung und HTML5 mit ausgereiftem Javascript ist REST mit JSON die am häufigsten verwendete Methode für den Umgang mit Diensten. Das definierte JSON-Schema kann auch für Lösungen auf Unternehmensebene verwendet werden (noch in einem frühen Stadium) ) bei Bedarf zusammen mit WADL.

PHP-Unterstützung für REST und JSON ist definitiv besser als die vorhandene eingebaute SOAP Unterstützung.

Fügen Sie hier ein paar weitere BUZZ-Wörter hinzu: SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

übrigens liebe ich SOAP speziell für die WS-Security-Spezifikation, dies ist eine gute Spezifikation, und wenn jemand an die Anpassung von Enterprise JSON denkt, muss er auf jeden Fall etwas Ähnliches für JSON mitbringen, wie zum Beispiel field Level-Verschlüsselung etc.

4
shivaspk

SOAP verkörpert einen serviceorientierten Ansatz für Webdienste - einen, bei dem Methoden (oder Verben) die wichtigste Art sind, wie Sie mit dem Dienst interagieren. REST verfolgt einen ressourcenorientierten Ansatz, bei dem das Objekt (oder das Substantiv) im Mittelpunkt steht.

4

Ein kurzer Punkt - Übertragungsprotokoll und Orchestrierung;

Ich verwende aus Gründen der Geschwindigkeit, Zuverlässigkeit und Sicherheit SOAP over TCP), einschließlich orchestrierter Machine-to-Machine-Services (ESB) und externer Services. Die Orchestrierung löst einen Fehler aus der WSDL-Änderung aus und ist sofort offensichtlich und kann neu erstellt/bereitgestellt werden.

Ich bin nicht sicher, ob Sie dasselbe mit REST - Ich warte auf eine Korrektur oder einen Kurs! Ändern Sie mit REST die Service-Definition - nichts weiß davon, bis es 400 (oder was auch immer) zurückgibt.

3
BlueChippy

Wenn Sie nach Interoperabilität zwischen verschiedenen Systemen und Sprachen suchen, würde ich mich auf jeden Fall für REST entscheiden. Ich hatte eine Menge Probleme damit, SOAP zum Beispiel zwischen .NET und Java zu arbeiten.

2
neu242

ich erstelle einen Benchmark, um herauszufinden, welche davon schneller sind! Ich sehe dieses Ergebnis:

für 1000 Anfragen:

  • REST dauerte 3 Sekunden
  • SOAP dauerte 7 Sekunden

für 10.000 Anfragen:

  • REST dauerte 33 Sekunden
  • SOAP dauerte 69 Sekunden

für 1.000.000 Anfragen:

  • REST dauerte 62 Sekunden
  • SOAP dauerte 114 Sekunden
2
Sonador

Eine alte Frage, die aber auch heute noch aktuell ist. Aufgrund der Tatsache, dass so viele Entwickler im Unternehmensbereich sie immer noch verwenden.

Meine Arbeit beinhaltet das Entwerfen und Entwickeln von IoT-Lösungen (Internet of Things). Dazu gehört die Entwicklung von Code für kleine eingebettete Geräte, die mit der Cloud kommunizieren.

Es ist klar, dass REST mittlerweile weit verbreitet und nützlich ist und so ziemlich der Standard für das Web, auch Microsoft hat REST Unterstützung in Azure enthalten. Wenn ich Ich musste mich verlassen SOAP Ich konnte nicht tun, was ich tun musste, da es für kleine eingebettete Geräte einfach zu groß, sperrig und ärgerlich ist.

REST ist einfach und sauber und klein. Ideal für kleine eingebettete Geräte. Ich schreie immer, wenn ich mit einem Webentwickler zusammenarbeite, der mir WSDLs sendet. Da muss ich eine Aufklärungskampagne beginnen, warum das einfach nicht funktioniert und warum sie REST lernen müssen.

0
Remixed123

1. Aus meiner Erfahrung. Ich würde sagen REST gibt Ihnen die Möglichkeit, auf die URL zuzugreifen, die bereits erstellt wurde. ZB-> eine Wortsuche in Google. Diese URL könnte als Webservice für REST verwendet werden. In SOAP können Sie erstellen Ihren eigenen Webdienst und greifen Sie über SOAP client darauf zu.

  1. REST unterstützt das Text-, JSON- und XML-Format. Somit vielseitiger für die Kommunikation zwischen zwei Anwendungen. While SOAP unterstützt nur das XML-Format für die Nachrichtenkommunikation.
0