Ist REST ein besserer Ansatz für Webdienste oder ist SOAP besser? Oder sind es unterschiedliche Werkzeuge für unterschiedliche Probleme? Oder handelt es sich um eine nuancierte Frage, d. h. ist das eine in bestimmten Bereichen etwas besser als das andere usw.?
Ich würde mich besonders über Informationen zu diesen Konzepten und deren Bezug zum PHP-Universum und auch zu modernen High-End-Webanwendungen freuen.
Als ich bei Hewlett-Packard arbeitete, baute ich einen der ersten SOAP-Server, einschließlich Code- und WSDL-Generierung, auf der Grundlage der ursprünglichen Spezifikation, als diese noch in der Entwicklung war. Ich empfehle NICHT, SOAP für irgendetwas zu verwenden.
Das Akronym "SOAP" ist eine Lüge. Es ist nicht einfach, es ist nicht objektorientiert, es definiert keine Zugangsregeln. Es handelt sich wohl eher um ein Protokoll. Es ist die schlechteste Spezifikation, die Don Box je entwickelt hat, und das ist eine ziemliche Leistung, denn er ist der Mann, der "COM" erfunden hat.
Es gibt nichts Nützliches in SOAP, was nicht auch mit REST für den Transport und JSON, XML oder sogar einfachem Text für die Datendarstellung möglich wäre. Für die Transportsicherheit können Sie https verwenden. Für die Authentifizierung: basic auth. Für Sitzungen gibt es Cookies. Die REST-Version ist einfacher, übersichtlicher, läuft schneller und verbraucht weniger Bandbreite.
XML-RPC definiert eindeutig die Anfrage-, Antwort- und Fehlerprotokolle, und für die meisten Sprachen gibt es gute Bibliotheken. Allerdings ist XML schwerer, als Sie es für viele Aufgaben benötigen.
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 grundlegend, erst die darauf aufbauenden WSS-*-Standards machen es sehr komplex.
Wenn Ihre Kunden andere Anwendungen und andere Server sind, gibt es heute viel Unterstützung für das SOAP-Protokoll, und die Grundlagen der Datenübertragung sind in modernen IDEs im Wesentlichen ein Mausklick.
Wenn Ihre Kunden eher RIAs oder Ajax-Clients sind, werden Sie wahrscheinlich etwas Einfacheres als SOAP und etwas Natives für den Client (vor allem JSON) wollen.
JSON-Pakete, die über HTTP gesendet werden, sind nicht unbedingt eine REST-Architektur, sondern nur Nachrichten an URLs. Das alles ist durchaus praktikabel, aber es gibt Schlüsselkomponenten der REST-Idiomatik. Es ist jedoch leicht, die beiden zu verwechseln. Aber nur weil Sie HTTP-Anfragen stellen, bedeutet das nicht unbedingt, dass Sie eine REST-Architektur haben. Sie können eine REST-Anwendung ganz ohne HTTP haben (wohlgemerkt, das ist selten).
Wenn Sie also über Server und Verbraucher verfügen, die mit SOAP "vertraut" sind, können SOAP und der WSS-Stack gute Dienste leisten. Wenn Sie mehr Ad-hoc-Sachen machen und eine bessere Schnittstelle zu Webbrowsern haben wollen, dann kann ein leichteres Protokoll über HTTP auch gut funktionieren.
REST ist ein grundlegend anderes Paradigma als SOAP. Eine gute Lektüre über REST finden Sie hier: Wie ich meiner Frau REST erklärt habe .
Wenn Sie keine Zeit haben, ihn zu lesen, hier die Kurzfassung: REST ist eine Art Paradigmenwechsel, indem es sich auf "Substantive" konzentriert und die Anzahl der "Verben", die man auf diese Substantive anwenden kann, einschränkt. Die einzigen erlaubten Verben sind "get", "put", "post" und "delete". Dies unterscheidet sich von SOAP, wo viele verschiedene Verben auf viele verschiedene Substantive (d. h. viele verschiedene Funktionen) angewendet werden können.
Bei REST entsprechen die vier Verben den entsprechenden HTTP-Anfragen, während die Substantive durch URLs identifiziert werden. Dies macht die Zustandsverwaltung viel transparenter als bei SOAP, wo oft unklar ist, welcher Zustand auf dem Server und welcher auf dem Client liegt.
In der Praxis fällt das meiste davon jedoch weg, und REST bezieht sich in der Regel nur auf einfache HTTP-Anfragen, die Ergebnisse in JSON , während SOAP eine komplexere API ist, die durch die Weitergabe von XML kommuniziert. Beide haben ihre Vor- und Nachteile, aber ich habe die Erfahrung gemacht, dass REST in der Regel die bessere Wahl ist, weil man nur selten, wenn überhaupt, die volle Funktionalität von SOAP benötigt.
Kurzer Überblick über die Frage für 2012:
Bereiche, in denen REST besonders gut funktioniert, sind:
Begrenzte Bandbreite und Ressourcen. Denken Sie daran, dass die Rückgabestruktur wirklich ein beliebiges Format hat (vom Entwickler definiert). Außerdem kann jeder Browser verwendet werden, da der REST-Ansatz die Standardverben GET, PUT, POST und DELETE verwendet. Denken Sie daran, dass REST auch das XMLHttpRequest-Objekt verwenden kann, das heute von den meisten modernen Browsern unterstützt wird, was einen zusätzlichen AJAX-Bonus darstellt.
Völlig zustandslose Operationen. Wenn ein Vorgang fortgesetzt werden muss, ist REST nicht der beste Ansatz, und SOAP ist vielleicht besser geeignet. Wenn Sie jedoch zustandslose CRUD-Vorgänge (Erstellen, Lesen, Aktualisieren und Löschen) benötigen, dann ist REST die richtige Wahl.
Caching-Situationen. Wenn die Informationen aufgrund des völlig zustandslosen Betriebs des REST-Konzepts zwischengespeichert werden können, ist dies perfekt.
Warum also sollte ich SOAP überhaupt in Betracht ziehen? Auch hier gilt, dass SOAP ziemlich ausgereift und gut definiert ist und über eine vollständige Spezifikation verfügt. Der REST-Ansatz ist genau das: ein Ansatz, der für die Entwicklung offen ist. Wenn Sie also die folgenden Voraussetzungen erfüllen, ist SOAP eine großartige Lösung:
Asynchrone Verarbeitung und Aufforderung. Wenn Ihre Anwendung ein garantiertes Maß an Zuverlässigkeit und Sicherheit benötigt, bietet SOAP 1.2 zusätzliche Standards, um diese Art von Betrieb zu gewährleisten. Dinge wie WSRM - WS-Reliable Messaging.
Formelle Verträge. Wenn sich beide Seiten (Anbieter und Nachfrager) auf das Austauschformat einigen müssen, gibt SOAP 1.2 die starren Spezifikationen für diese Art der Interaktion vor.
Zustandsabhängige Operationen. Wenn die Anwendung kontextbezogene Informationen und die Verwaltung des Gesprächszustands benötigt, dann verfügt SOAP 1.2 über die zusätzlichen Spezifikationen in der WS*-Struktur, um diese Dinge zu unterstützen (Sicherheit, Transaktionen, Koordination usw.). Im Vergleich dazu würde der REST-Ansatz die Entwickler dazu zwingen, diese benutzerdefinierten Leitungen zu erstellen.
SOAP hat derzeit den Vorteil besserer Tools, die einen Großteil des Boilerplate-Codes sowohl für die Serviceschicht als auch für die Generierung von Clients aus einer gegebenen WSDL generieren.
REST ist einfacher, kann daher leichter gewartet werden, bildet das Herzstück der Web-Architektur, ermöglicht eine bessere Sichtbarkeit des Protokolls und ist nachweislich mit der Größe des WWW selbst skalierbar. Einige Frameworks helfen bei der Erstellung von REST-Diensten, wie Ruby on Rails, und einige helfen sogar beim Schreiben von Clients, wie ADO.NET Data Services. Aber in den meisten Fällen fehlt es an Tool-Unterstützung.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
