Warum sollte man REST anstelle von SOAP-basierten Diensten verwenden? [geschlossen]

Ich habe heute an einer interessanten Demo zu REST teilgenommen, konnte mir jedoch keinen einzigen Grund vorstellen (noch wurde einer vorgestellt), warum REST ohnehin besser oder einfacher zu verwenden und zu implementieren ist als ein SOAP-basierter Services-Stack.

Was sind einige der Gründe, warum jemand in der "realen Welt" REST anstelle der SOAP-basierten Dienste verwendet?

Weniger Overhead (kein SOAP-Umschlag zum Einwickeln jedes Anrufs)

Weniger Duplizierung (HTTP repräsentiert bereits Vorgänge wie DELETE, PUT, GET usw., die ansonsten in einem SOAP-Umschlag dargestellt werden müssen).

Standardisierter - HTTP-Vorgänge sind gut verstanden und funktionieren konsistent. Einige SOAP-Implementierungen können schwierig werden.

Besser lesbar und testbar (schwieriger, SOAP mit nur einem Browser zu testen).

Sie müssen kein XML verwenden (für SOAP müssen Sie das auch nicht, aber es macht kaum Sinn, da Sie bereits den Umschlag analysieren).

Bibliotheken haben SOAP (irgendwie) einfach gemacht. Aber Sie abstrahieren viel Redundanz darunter, wie ich bemerkt habe. Ja, theoretisch kann SOAP andere Transporte durchlaufen, um zu vermeiden, dass auf einer Ebene ähnliche Dinge ausgeführt werden. In Wirklichkeit erfolgt jedoch fast jede SOAP-Arbeit, die Sie jemals ausführen werden, über HTTP.

RESTful- Services sind viel einfacher zu nutzen als SOAP- basierte (reguläre) Services. Der Grund dafür ist, dass REST auf normalen HTTP-Anforderungen basiert, wodurch die Absicht aus dem Typ der gestellten Anforderung abgeleitet werden kann (GET = Retrive, POST = Write, DELETE = Remove, etc ...) und vollständig zustandslos ist. Auf der anderen Seite könnte man argumentieren, dass es weniger flexibel ist, da es das Konzept eines Nachrichtenumschlags, der den Anforderungskontext enthält, aufhebt.

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 gemacht werden.

Mit Tools wie WCF im .NET Framework ist es sehr trivial, einen Service als REST oder SOAP zu implementieren.

Einige relevante Lektüre:

• Amazon Web Services-Blog: REST vs SOAP
• Dare Obasanjo schreibt oft über REST

Ich gehe davon aus, dass Sie mit "Web Services" SOAP und die WS- * -Standards meinen. (Sonst könnte ich argumentieren , dass REST - Service ist "Web - Service") .

Das kanonische Argument ist, dass REST-Services dem Design des Webs, dh dem Design von HTTP und der zugehörigen Infrastruktur, besser entsprechen. Die Verwendung eines REST-Service ist daher besser mit vorhandenen Web-Tools und -Techniken kompatibel.

Wenn Sie sich mit Einzelheiten befassen, stellen Sie natürlich fest, dass beide Ansätze in unterschiedlichen Szenarien Stärken haben. Sind es diese Besonderheiten, die Sie interessieren?

Der Overhead ist nicht so wichtig wie eine gute Architektur.

REST ist kein Protokoll, sondern eine Architektur, die ein 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 die vorhersehbaren Kosten für RESTful-Protokolle über HTTP, da vorhandene Technologien (hauptsächlich Proxys) genutzt werden können. Die anfänglichen RPC-Kosten sind recht niedrig, steigen jedoch mit zunehmender Lastintensivierung tendenziell erheblich an.

REST ist implementierungsunabhängig und viel transparenter. Dies macht es ideal für öffentliche APIs, insbesondere für große Websites wie Flickr, Amazon oder Digg, die ihre APIs als Marketing-Tools verwenden und wirklich möchten, dass Benutzer ihre Daten konsumieren. Sie möchten nicht 1000 unerfahrene Entwickler in der Hand halten, die versuchen, die fehlerhafte SOAP-Bibliothek ihrer Skriptsprache ihrer Wahl zu debuggen.

Im Vergleich zu SOAP und WSDL, die besser für interne Anwendungen geeignet sind, bei denen Sie an beiden Enden Drop-In-Bibliotheken und bekannte Hinweise haben. (Und Sie müssen sich möglicherweise nicht um Dinge wie Lastausgleich im Internet-Maßstab, HTTP-Caching usw. kümmern.) Dann erhalten Sie APIs, die selbst dokumentiert sind, Typen usw. ohne Arbeit beibehalten.

Ich muss Roy Fieldings hervorragendste Dissertation zu diesem Thema lesen . Er ist ein ausgezeichneter Fall und war auf jeden Fall WAY seiner Zeit voraus , als er es schrieb (2000).

Steve Vinoskis Blog und seine neuesten Artikel sind definitiv einen Blick wert. Er ist ein ehemaliger CORBA-Guru, der mit Michi Henning das wahrscheinlich beste Buch zu diesem Thema geschrieben hat: "Advanced CORBA® Programming with C ++" . Seitdem hat er jedoch den Fehler seiner Client / Server-Methoden erkannt und schwört nun auf REST.

Mit REST können Ihre nicht mutierenden Operationen (die im Allgemeinen das GET-Verb verwenden) zwischengespeichert werden . Das heißt, vom Client zwischengespeichert und / oder von Proxys zwischengespeichert. Dies kann ein großer Gewinn sein!

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, auf die Sie zugreifen möchten.

http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer

Es ist super einfach und schlank. Sie können dies mit dem Browser über http verb: GET tun. Ich habe keinen Browser gefunden, der generische http POST-Anfragen einfach manuell ausführen kann

Hier ist ein Datenpunkt: Amazon bietet seine APIs sowohl im REST- als auch im SOAP-Format an und 85% der Nutzung erfolgt über REST.

REST ist einfacher zu implementieren, leichter zu verstehen und bietet eine höhere Leistung.