«Ruhelose» Web Services

Heutige Geschäftsanwendungen verwenden typischerweise Daten und Funktionen aus verschiedensten Systemen, teilweise auch über (Firmen-)Grenzen hinweg. Sie erfordern daher geeignete Technologien, um diese verteilten Systeme miteinander effizient kommunizieren zu lassen und sie auch leicht wartbar zu gestalten. In den letzten Jahren wurden vor allem W3C Web Services – zu denen unter anderem SOAP und WSDL zählen – mit einem Service-orientierten Architekturparadigma eingesetzt, um diese Anforderungen zu erfüllen. SOAP Web Services sind in vielen Fällen eine gute Wahl, denn sie erlauben eine strenge Definition der Services sowie auch der zu übertragenden Daten. Gleichzeitig sind Web Services aber auch eine sehr schwergewichtige Technologie, die eine Vielzahl von zum Teil komplexen Protokollen und Middleware-Systemen erfordert.

In den letzten Jahren wurde daher auch von verschiedener Seite Kritik über diesen Ansatz laut, besonders in Anwendungsfällen, wo der Datenaustausch und weniger Funktionsaufrufe im Vordergrund stehen. Statt dessen wurden alternative leichtgewichtige Architekturansätze wie REST vorgeschlagen.

REST: Ressourcen, Identifier und Repräsentationen

Der Begriff REST ist die Abkürzung für den etwas sperrigen Namen «Representational State Transfer» und wurde vom HTTP-Miterfinder Roy Fielding eingeführt. So schwierig der Titel auch sein mag, die Idee ist einfach und bestechend: Die konzeptionell wesentlichsten Begriffe im REST-Umfeld sind Ressource und deren Identifier sowie die Repräsentation der Ressource (siehe Grafik links).



Ressourcen sind, wie der Name schon sagt, Datenelemente oder Ziele einer Anfrage. Dies kann man leicht an einem Beispiel verdeutlichen: Eine Person könnte eine Ressource sein oder ein Artikel in der Datenbank. Jede Ressource ist durch einen eindeutigen Identifier (dies ist üblicherweise eine URL) bestimmt. Dieser Identifier sollte aber selbstbeschreibend sein (wie http://www.example.com/webshop/item/i4325_digital_camera). Ein Client könnte nun eine Anfrage (Request) an diese über den Identifier bestimmte Ressource stellen und würde vom Server ein Ergebnis (Reply) zurückbekommen.

An dieser Stelle kommt das dritte wichtige Konzept ins Spiel: die Repräsentation. Eine Ressource ist ja ein mehr oder weniger abstrakter Begriff wie «Kunde». Wird nun ein Request auf einen bestimmten Kunden durchgeführt, so kann diese Ressource in verschiedenster Weise (je nach Problemstellung) repräsentiert werden. Der Reply könnte also beispielsweise sein:



- ein Foto des Kunden (als JPEG)

- die Stammdaten des Kunden in einem XML-Format

- die Stammdaten des Kunden druckfertig aufbereitet als PDF

- Stammdaten in XML sowie eine Liste von Links mit Beziehungen dieser Person zu anderen Personen (z.B. für ein soziales Netzwerk)



Aus technischer Sicht betrachtet werden REST-basierte Anwendungen auch als Web-style Programming bezeichnet. Die Idee dabei ist, dass es bereits eine Architektur für massiv skalierende verteilte Systeme gibt und keine neue erfunden werden muss, nämlich das World Wide Web mit seinen Protokollen wie HTTP. Eine REST-Anwendung verwendet daher auch nur die vier Methoden, die das HTTP-Protokoll definiert: GET, um Ressourcen zu lesen, PUT und POST, um sie zu schreiben, DELETE, um sie zu löschen. Dabei wird gefordert, dass die GET-Methode nicht zu Änderungen der Daten am Server führen darf.



Der Client greift per HTTP auf eine über eine URL spezifizierte Ressource zu. Dabei erhält er (GET) dann eine Repräsentation der Ressource zurück oder verändert (PUT, DELETE) die Ressource am Server. Die Repräsentation in REST-Anwendungen ist sehr häufig XML, das vom Client dann weiter verarbeitet werden kann. Die Grafik «REST im Vergleich zu RPC» stellt das uniforme Interface von REST dem non-uniformen Interface gängiger RPC-Mechanismen gegenüber. Auch Links werden im REST-Konzept verwendet. Möchte man eine Liste von Bestellungen an den Client zurückgeben, könnte diese Liste nur einen Überblick darstellen und Links zu den Details jeder Bestellung erhalten, die der Client bei Bedarf anfordern kann.


Ein weiteres wichtiges Prinzip von REST-Architekturen ist, dass einzelne Zugriffe zustandslos sein sollen. Ein Zugriff soll also nicht von anderen Zugriffen davor abhängig sein. Das bedeutet, dass bei jedem Zugriff alle vom Server benötigten Informationen übertragen werden müssen. Dies hat zur Folge, dass Zustandsinformationen auf dem Client gehalten werden.



Illustration der REST-Idee

Leichtgewichtig

REST-Anwendungen sind im allgemeinen wesentlich leichtgewichtiger als vergleichbare Web-Service-Architekturen. In manchen Diskussionen wird daher versucht, REST gegen Web Services zu positionieren. Tatsächlich ist es vermutlich eher so, dass beide Ansätze klare Vor- und Nachteile haben. Web Services sind beispielsweise viel strenger definiert. Repräsentationen in REST werden häufig geradezu bewusst nicht zu streng (beispielsweise über XML-Schemas) spezifiziert, um eine grössere Fehlertoleranz und Flexibilität in der Anwendung zu ermöglichen.


Zwei Philosophien treffen auch aufeinander, wenn es um die Frage geht, wie ein Client mit einem Service interagieren sollte. Viele Web Service Frameworks versuchen hier, den eigentlichen Serviceaufruf für den Entwickler möglichst zu verstecken. Für den Entwickler stellt sich der Serviceaufruf im Prinzip wie ein lokaler Methodenaufruf dar. Darin liegt eine Stärke, aber auch eine potentielle Gefahr des Ansatzes bezüglich Performance und Sicherheit. Einige Vertreter des REST-Stils sind daher der Meinung, dass der Aufruf nichtlokaler Services auch als solcher erkennbar sein und nicht hinter APIs versteckt werden sollte: Einerseits um dem Entwickler klar zu zeigen, dass es eben kein lokaler Methodenaufruf, sondern ein potentiell teurer externer Serviceaufruf ist, andererseits auch, um an dieser Stelle das Bewusstsein zu schaffen, dass der Datenaustausch hier über Systemgrenzen hinweggeht und somit besondere Beachtung verdient (unter anderem bezüglich Validierung der Daten).

In der Praxis zeigt sich, dass Webstyle Programmig mit REST sehr gerne dort eingesetzt wird, wo man auf breiter Basis mit sehr vielen verschiedenen Clients kommunizieren möchte. So verwenden viele Yahoo- und Google-Anwendungen REST-Schnittstellen, ebenso einige Web-2.0-Anwendungen wie del.icio.us. Denn REST-Ressourcen können sogar im normalen Webbrowser geladen und angezeigt werden, die Entwicklung von Clients ist in allen Programmiersprachen sehr einfach. Durch die Verwendung von Internetstandards wie HTTP sowie dem zustandslosen Ansatz können Serviceanbieter auf erprobte Technologien zur Skalierung wie Caches und Load Balancer zurückgreifen, die ohnehin schon für Webanwendungen verwendet werden.

Apache ActiveMQ

REST ist leichtgewichtig und kann im Prinzip mit den Bordmitteln der meisten Programmiersprachen verwendet werden. Dennoch können Frameworks und Middleware-Komponenten die Entwicklung von REST-Anwendungen sehr erleichtern beziehungsweise REST-Systeme in konventionelle Architekturen integrieren. Im Pool der Apache Software Foundation finden sich auch einige Projekte, die hier hilfreich sein können.


Der Message Broker Apache ActiveMQ (siehe auch Heft 2007/14) ist nicht nur ein JMS Broker, sondern erlaubt auch Protokolltransformationen. Konkret für REST bedeutet dies, dass ActiveMQ eine REST API zur Verfügung stellt, mit der beispielsweise per HTTP eine Nachricht an ActiveMQ gesandt werden kann.

Wird per POST eine Nachricht gesendet, so packt ActiveMQ diese in eine JMS-Nachricht und legt sie in die Queue ab. Auch der umgekehrte Weg ist möglich: Mittels GET-Anfrage kann die Queue abgefragt werden, sodass eine dort vorhandene JMS-Nachricht als REST-Ressource zur Verfügung gestellt wird. Daran zeigt sich sehr schön, wie man Middleware einsetzen kann, um für die jeweilige Problemstellung die passende Lösung zu wählen, sei dies JMS, REST oder ein anderes Protokoll.

REST für Integrations-Middleware

Im Apache-Pool finden sich auch zwei Web-Service-Bibliotheken: Axis 2 und das jüngere CXF. Der Schwerpunkt dieser Projekte liegt auf der Implementierung von W3C Web Service Standards wie SOAP, WSDL, WS-Addressing oder Reliable Messaging. Was weniger bekannt ist: Beide Projekte bieten auch Unterstützung für REST-Anwendungen. Dies bedeutet konkret, dass man Services sowohl via SOAP als auch über ein REST-API anbieten kann. Damit kann man dem Client die Wahl lassen, welches Protokoll bevorzugt wird.


Auch Enterprise Service Busses wie Apache Service Mix oder Mule verwenden Projekte wie CXF, um REST Endpoints zu ermöglichen. Durch das uniforme Interface (Grafik rechts) werden auch Mash-ups leichtgemacht. Es können also XML-Repräsentationen verschiedener REST Services einfach integriert werden. Als Beispiel für einen Mash-up-Service könnte man Yahoo Pipes nennen.



Mittlerweile gibt es auch freie REST-Bibliotheken wie Restlet im Java-Umfeld. Welcher Frameworks man sich konkret bedienen möchte, hängt vom Kontext der eigenen Anwendung ab.

Sehr beliebt

Der REST-Architekturstil erfreut sich stark wachsender Beliebtheit. Offenbar leiden viele Entwickler noch an einem «Kater» vom intensiven Einsatz verschiedenster Web-Service-Protokolle. Das Entwicklungsparadigma von REST unterscheidet sich deutlich vom Ansatz der Web Services. Es ist sehr leichtgewichtig, einfach zu erlernen und baut auf jahrzehntelang erprobten Technologien auf, die erwiesenermassen massiv skalieren und sehr fehlertolerant sind.

Mittlerweile gibt es auch eine Vielzahl an Middleware-Produkten und Frameworks wie ActiveMQ, die eine elegante Integration von REST-Services auch in bestehende Architekturen einfach gestaltet beziehungsweise parallel verschiedene Ansätze betreiben lässt.


REST-Ansätze werden Webservices sicher nicht ablösen – beide Architekturparadigmen haben klare Vor- und Nachteile und können parallel für verschiedene Problemstellungen zum Einsatz gebracht werden.




REST im Vergleich zu RPC



Web-style Programming

Der Autor

Alexander Schatten (alexander@schatten.info) ist Assistent am Institut für Softwaretechnik und interaktive Systeme der Technischen Universität Wien.