REST vs. SOAP: Wohin geht die Reise?
Schon seit geraumer Zeit beherrscht die Diskussion um „REST vs. SOAP“ die Welt der SOA-Entwicklung. REST, ein Akronym für REpresentational State Transfer, stellt dabei eine mehr oder minder andere Herangehensweise zur Erstellung von Webservices im Vergleich zu SOAP und WSDL dar. Die Grundidee des Architekturstils von REST geht auf die Dissertation von Thomas Roy Fielding aus dem Jahre 2000 zurück.
Die Prinzipien von REST weisen starke Parallelen zu einer der größten verteilten Anwendung auf: zu dem World Wide Web (WWW). Bis vor kurzem wurde mit dem Thema Webservice nahezu automatisch die WS-* Welt rund um SOAP assoziiert. Doch der Architekturstil REST genießt immer mehr Bekannheitsgrad. Bereits heute setzt beispielsweise Google bei seinen neueren APIs auf REST. Auch Microsoft verfolgt mit seinem Projekt Astoria ähnliche Ziele.
Die Analystin Anne Thomas Manes von der Burton Group sieht die Zukunft von SOA ganz klar in REST. Mit ihrer Aussage „The Web is REST. REST is the web“ gab sie der Themenstellung „REST vs. SOAP“ eine ganz klare Richtung.
Aber nicht nur aus Analystensicht sondern auch mit Blick durch die technische Brille lässt sich der Trend klar erkennen. So setzen immer mehr bekannte Frameworks wie Axis2, Ruby on Rails oder die neue Version von Microsoft WCF auf REST. Auch in der Welt von Java ist eine Bewegung zu verzeichnen. So hört der JSR 311 auf den Namen „JAX-RS: The Java API for RESTful Web Services“. Unter dem Namen Jersey ist die zugehörige Referenzimplementierung auch gleich verfügbar. Die Implementierung spiegelt dabei den aktuellen Status zum JSR 311 wieder. Vielmehr kann diese aber auch als Baukasten verstanden werden. Jersey unterstützt nämlich verschiedene Erweiterungspunkte und -möglichkeiten. An der Stelle sei aber angemerkt, dass Jersey derzeit wohl nur zum „Spielen und Ausprobieren“ reichen dürfte. Schließlich handelt es sich aber auch noch um ein frühes Entwicklungsstadium.
Insgesamt betrachtet zeigt die SOA Welt damit wieder mehr Spannung. Wobei ich derzeit der Meinung bin, dass sich sowohl REST als auch SOAP als Webservices halten werden. In gewisser Weise stehen zwar beide Ansätze in Konkurrenz zueinander. Andersherum betrachtet verfolgen sie aber durchaus auch andere Ansätze. So kommt es auch meiner Sicht sehr stark darauf an was man mit einem Webservice erreichen will.
Danke für den tollen Beitrag.
Anscheinend scheint sich ja REST durchzusetzen.
Bin schon gespannt auf die weitere Entwicklung dieser beiden Standards.
Hallo Markus,
ich merke schon, hier schreibt jemand der sich mit der Materie bestens auskennt und offensichtlich auf Erfahrung zurückgreifen kann.
Wenn ich heute das Thema CORBA in den Mund nehme, dann befürchte ich immer wieder als „Old-Fashioned“, „Old-Economy“ oder einfach nur konservativ bezeichnet zu werden. Dabei kommt es mir eigentlich nur darauf an, Technikdiskussionen differenzierter zu betrachten und nicht immer auf das Neuste vom Neusten aufzuspringen -wie es imho der Markt viel zu schnell praktiziert.
Jedenfalls freut es mich solche Erfolgsberichte mit CORBA nicht nur von doubleSlash zu hören.
Schönen Gruss vom Bodensee
Hallo Oliver,
das „zu kompliziert“ war zynisch gemeint.
Ich habe vor einigen Jahren einen CORBA basierenden Servicebus konzipiert und aufgebaut. Hier haben wir die gleichen Erfahrungen gemacht. Performance, Skalierbarkeit, Fehlertoleranz, Failover etc. sind mit CORBA einfach zu erreichen, mit SOAP hab ich da zu meine Zweifel. Darüber hinaus hat IDL mit den Language-Bindings gegenüber SOAP unschlagbare Vorteile. Wir haben die Erfahrung gemacht, dass IDL sogar in der Projekt-Abstimmung zwischen Cobol-Hosties und Java-Jüngern ein sehr guter Weg ist, die Sprach-Bariere zu überwinden…
Markus
Hallo Markus,
in der Diskussion könnten wir ein riesen Fass öffnen und über die Vor- und Nachteile von CORBA schreiben. Da du mit deinem Statement „zu kompliziert“ aber genau die Gegenposition von mir vertrittst muss ich da – mit unserer Erfahrung- heftigst widersprechen. Genau das Gegenteil ist der Fall.
Sämtliche SOA-Plattformen haben wir via CORBA aufgebaut und dabei erfahren, dass eine sauber dokumentierte IDL auch von Nichttechniker halbwegs verstanden wird.
Probleme gab es eigentlich immer nur dann, wenn -so wie du sagst- ein Vertragspartner Defizite im Aufbau einer solchen Architektur hatte.
Hauptgrund meiner Anmerkung ist allerdings das Uralt-Thema: Performance.
CORBA ist und bleibt bei Massendatenverarbeitung unschlagbar und diejenigen die fälschlicher Weise im Zusammenhang mit Ajax-Anwendungen direkt auf SOAP-Dienste aufsetzten machten alle samt lange Gesichter wegen den langen Laufzeiten. Als genau das Gegenteil was man mit Ajax-Anwendungen erreichen will.
Drum: CORBA ist tod, lang lebe SOA mit CORBA und Ajax.
Schönen Gruss
CORBA ist leider für viele Leute schon abgeschrieben, obwohl es die Vorteilen von beiden Ansätzen vereint.
Es hat auf der einen Seite eine formale Schnittstellenbeschreibung mit statischer Typ-Prüfung (ISO-IDL).
Auf der anderen Seite ist jedes CORBA-Objekt über seine IOR ähnlich wie die URI beim REST-Ansatz eindeutig zu identifizieren.
Leider bringt CORBA aber so viel Spezifikation mit sich, dass viele Middlewarehersteller nicht in der Lage waren diese mit ausreichender Qualität zu implementieren. Desweitern überfordern Konzepte wie „Tie-Approch“ und POA viele „Entwickler“, die mit einem schnellen Hack mal eben einen Show-Case für einen Service basteln möchten…
Last but not least ist der Ansatz „Contract first“ in vielen Projekten nicht verstanden. Man bastelt lieber an irgenwelchen Java/C#/Sonstwas-Klassen und veröffentlicht dann die Signatur der Klassen als „Service“ …
Warum fällt eigentlich immer CORBA aus der Betrachtung raus? CORBA hat einige wichtige Vorteile gegenüber REST und SOAP und wird imho bei SOA viel zu sehr unterschätzt.