Heute fand eine interessante Demo zu REST statt, aber ich konnte mir keinen einzigen Grund vorstellen (noch wurde einer vorgestellt), warum REST sowieso besser oder einfacher zu verwenden und zu implementieren ist als ein SOAP-basierter Services-Stack.Warum sollte man REST anstelle von SOAP-basierten Diensten verwenden?
Was sind einige der Gründe, warum jemand in der "realen Welt" REST anstelle der SOAP-basierten Dienste verwendet?
weniger Overhead
Weniger Duplizierung (HTTP bereits stellt Operationen wie DELETE, PUT, GET, usw., die haben sonst in einem SOAP-Umschlag dargestellt werden) (kein SOAP-Umschlag jeden Anruf in wrap).
Mehr standardisiert - HTTP-Operationen sind gut verstanden und arbeiten konsistent. Einige SOAP-Implementierungen können knifflig werden.
Mehr menschlich lesbar und testbar (schwieriger zu SOAP mit nur einem Browser zu testen).
Sie müssen nicht XML verwenden (Sie müssen auch nicht für SOAP, aber es macht kaum Sinn, da Sie bereits den Umschlag analysieren).
Bibliotheken haben SOAP (Art) einfach gemacht. Aber Sie abstrahieren eine Menge Redundanz darunter, wie ich festgestellt habe. Ja, in der Theorie kann SOAP über andere Transporte gehen, um zu vermeiden, dass man auf einer Schicht reitet, die ähnliche Dinge tut, aber in Wirklichkeit wird SOAP nur über HTTP laufen.
Ich möchte hinzufügen, dass die SOAP-Kommunikation zwischen den Plattformen auch eine PITA sein kann (war das nicht der Punkt von SOAP?!?). –
Auch gut mit HTTP-Infrastruktur - z.GETs werden aggressiv zusammen mit der Verwendung von zuletzt geändert und Etags –
Working groß mit Web-Browsern, um einen universellen Client zu Ihren Diensten bieten hilft auch :) –
REST ist im Grunde nur eine Möglichkeit, Webdienste zu implementieren. Es ist nur eine Möglichkeit, HTTP korrekt zu verwenden, um die Webdienste abzufragen, die Sie versuchen zu schlagen.
http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer
REST hat nichts mit HTTP zu tun und ist vollständig protokollunabhängig. Es eignet sich jedoch gut für einige Arten von ressourcenorientierten Webdiensten. – aehlke
Ich werde davon ausgehen, dass, wenn Sie "Web-Services", sagen Sie SOAP und WS- * Reihe von Standards bedeuten. (Sonst könnte ich argumentieren, dass REST-Service sind „Web-Service“).
Das kanonische Argument ist, dass die REST-Service eine bessere Übereinstimmung mit dem Design der Bahn ist - das heißt, die Gestaltung von HTTP und die damit verbundener Infrastruktur . Daher ist die Verwendung eines REST-Dienstes kompatibler mit vorhandenen Web-Tools und -Techniken.
Natürlich, sobald Sie in die Details bohren, finden Sie heraus, dass beide Ansätze Stärken in verschiedenen Szenarien haben. Sind Sie an diesen Details interessiert?
RESTful Dienstleistungen sind viel einfacher zu konsumieren als SOAP basierte (regelmäßige) Dienste. Der Grund dafür ist, dass REST auf normalen HTTP-Anfragen basiert, die es ermöglichen, die Absicht aus dem Typ der Anfrage abzuleiten (GET = retrive, POST = schreiben, DELETE = entfernen, etc ...) und völlig zustandslos ist. Auf der anderen Seite könnte man argumentieren, dass es weniger flexibel ist, da es mit dem Konzept eines Nachrichtenumschlags, der einen Anforderungskontext enthält, wegfällt.
Nach meiner Erfahrung wurde SOAP für Dienste innerhalb des Unternehmens bevorzugt, und REST wurde für Dienste bevorzugt, die als öffentliche APIs verfügbar sind.
Mit Tools wie WCF im .NET-Framework ist es sehr trivial, einen Dienst als REST oder SOAP zu implementieren.
Einige relevante Literatur:
Nach meinem Verständnis können WSDL-Dateien zum Generieren von Klassen verwendet werden, um die Web-Service-Methoden verfügbar zu machen. Sicher macht dies den Verbrauch der Dienste so einfach wie das Anrufen einer Funktion? Können Sie Ihren Blick bitte etwas mehr erklären? –
Howard May: Angenommen, Sie rufen Funktionen nur mit primitiven Datentypen auf, das ist sicherlich richtig. Aber in diesem Fall kann man nicht genau argumentieren, dass SOAP einfacher ist als Ruhe. Wenn Sie über komplexe Datentypen verfügen, funktioniert die WSDL-Verarbeitung möglicherweise problemlos zwischen zwei Computern mit denselben WS-Stapeln. Aber Sie werden unweigerlich Probleme haben, sobald Sie Stapel mischen. Es hört auf, so einfach zu sein, wenn Sie sich erst einmal manuell mit WSDL beschäftigen müssen, um Inkompatibilitäten zu beheben. –
Im Jahr 2014 unterstützt fast jede Plattform, auch die alten, WSDL. Proxy-Klassen machen die Verwendung der API extrem einfach. Wir implementieren einen Push-Service und ich denke über REST nach, aber ich habe wirklich Probleme, Vorteile zu sehen. – JohnOpincar
Got Roy Fieldings trefflichsten dissertation zum Thema zu lesen. Er macht einen ausgezeichneten Fall und war definitiv WAY seiner Zeit voraus, als er es schrieb (2000).
Steve Vinoski's blog und seine latest articles sind auf jeden Fall einen Besuch wert. Er ist ein ehemaliger CORBA-Guru, der mit Michi Henning das wohl beste Buch zu diesem Thema geschrieben hat, "Advanced CORBA® Programming with C++". Seitdem hat er jedoch den Fehler seiner Client/Server-Wege gesehen und schwört nun auf REST.
Es ist super einfach und schlank. Sie können es mit dem Browser über http Verb: GET tun. Ich kann nicht finden, dass ein Browser manuell generische http POST Anfrage leicht
Kasse Fiddler. Es ist kein Browser, aber es ist eine großartige Möglichkeit, HTTP-POSTs ohne Code zu erstellen. http://fiddler2.com/fiddler2/ –
Ich mache es normalerweise mit der Änderung bestehender Anfrage mit Charles. Ich habe auch Fiddler. –
REST ist Implementierung-Agnostic und viel mehr transparent, und das macht es ideal für öffentliche APIs, vor allem für große Websites wie Flickr, Amazon oder Digg nutzen ihre APIs als Marketing-Tools und wollen wirklich, dass die Leute ihre Daten konsumieren. Sie nicht wollen Hand-halten 1000s Anfänger Entwickler, die versuchen, ihre Skriptsprache der Wahl Buggy SOAP-Bibliothek zu debuggen.
Versus SOAP und WSDL, die besser für interne Anwendungen sind, wo Sie Drop-in-Bibliotheken und bekannte kluge Menschen an beiden Enden haben. (Und Sie müssen sich vielleicht nicht um Dinge wie Lastenausgleich im Internet, HTTP-Caching usw. kümmern.) Dann erhalten Sie APIs, die selbst dokumentiert sind, Typen usw. mit null Arbeit beibehalten.
Eine gute Antwort, aber ich würde nicht zustimmen, dass SOAP bedeutet, dass Sie keinen Lastenausgleich im Internet haben können. – HDave
Mit REST können Ihre nicht mutierenden Operationen (die normalerweise das GET-Verb verwenden) zwischengespeichert sein. Das heißt, zwischengespeichert vom Client und/oder zwischengespeichert von Proxies. Dies kann ein großer Gewinn sein!
Das ist einfach "HTTP richtig verwenden" und nicht REST. – aehlke
Der Overhead ist nicht so wichtig wie eine gute Architektur.
REST ist kein Protokoll, es ist eine Architektur, die gutes skalierbares Design fördert. Es wird oft gewählt, weil zu viel Freiheit in RPC leicht zu einem schlechten Design führen kann.
Der andere Grund sind vorhersehbare Kosten für REST-konforme Protokolle über HTTP, da vorhandene Technologien (hauptsächlich Proxys) genutzt werden können. Die anfänglichen Kosten von RPC sind ziemlich niedrig, neigen jedoch dazu, bei Lastverstärkung signifikant zuzunehmen.
Hier ist ein Datenpunkt: Amazon bietet seine APIs sowohl in REST-und SOAP-Formate und 85% der Nutzung ist REST.
REST ist einfacher zu implementieren, leichter zu verstehen und höhere Leistung.
Haben Sie Referenzen für Ihre Aussage "höhere Leistung"? –
Woher hast du die 85% Nutzung? Das ist sehr gut zu wissen (wenn ich Beweise sehen kann) – schmoopy
Manuelles Lesen einer API-Spezifikation, Drucken von Seiten usw. ist einfacher zu implementieren als "Rechtsklick, Service-Referenz hinzufügen"? (VS2010) – BlueChippy
Mit Web Services beziehen Sie sich auf SOAP Style Web Services? Soweit ich weiß, können Sie auch RESTful-Web-Services nutzen. –