Ein neues Feature von Spring 3 ist die Unterstützung von REST. Dieser Architektur-Ansatz für verteilte Systeme nutzt HTTP und die Ansätzes des Webs deutlich anders, als man dies zum Beispiel von Web Services gewohnt ist. Wie man technisch REST-Anwendungen implementiert sollte klar sein - eben mit Spring 3. Aber ist bei diesem Ansatz zu beachten?

Genau diesen Bereich deckt Stefan Tilkov mit seinem Buch "REST und HTTP: Einsatz der Architektur des Web für Integrationsszenarien" ab. Es enthält eine ausführliche Darstellung des REST-Ansatzes als Architektur und beantwortet daher genau die Fragen, die man bei einem Einstieg in REST hat. Man kann an dem Buch deutlich erkennen, dass der Autor viele Erfahrungen im Bereich Architektur und insbesondere REST gesammelt hat. Er wägt verschiedene Ansätze ab, kommt zu schlüssigen Empfehlungen und betrachtet das gesamte Thema erfrischen unideologisch. Auch die Abgrenzung zu den WS-*-Technologien gelingt so sehr gut und nachvollziehbar. Die zum Teil dann doch spitzen Kommentare finden sich in den Fußnoten und dienen eher der Auflockerung.

Das Buch führt zunächst kurz in REST ein, um dann das Gezeigte durch eine Fallstudie in der Praxis zu zeigen. Dann werden die wesentlichen Elemente (Ressourcen, Verben, Hypermedia, Repräsentationsformate) detailliert erläutert und am Beispiel des Atom-Protokolls praktisch verdeutlicht.

Schließlich geht es um Features wie Sitzungen, Skalierbarkeit, Caching, Sicherheit, Dokumentation und erweiterte Anwendungsfälle, die dann an einer Erweiterung der ersten Fallstudie praktisch gezeigt werden. Dabei wird die Fallstudie komplexer und deckt viele typische Anforderungen im Enterprise-Umfeld ab. Den Abschluss bildet eine Betrachtung zu "Enterprise SOA mit REST".

Insgesamt ist das Buch eine kurzweilige, kompakte und sehr gut gelungene Einführung in REST und auf jeden Fall zu empfehlen.

Wer gleich zugreifen will:





bzw.

REST und HTTP: Einsatz der Architektur des Web für Integrationsszenarien

Ich war schon immer ein Freund davon, nicht alles selbst zu erfinden, sondern den Austausch mit anderen zu suchen und Best Practices anzunehmen. Um so mehr war ich erfreut, in der IT-Szene München eine Vortragsankündigung der JBoss User Group München zum Thema “Java API for RestFul Web Services und RESTEasy” zu finden. REST wurde bei uns schon länger als mögliche Schnittstelle für neue Clients diskutiert, ohne daß ich eine Ahnung gehabt hätte wie sich dieses “Protokoll” von den bisher verwendeten WebServices unterscheidet.

Die wichtigste Erkenntnis vorneweg: REST ist kein weiteres Protokoll, um Clients anzubinden sondern ein eigener Architekturstil, der zu einem anderen Anwendungsentwurf führt. Die Referenten Stefan Tilkov und Serge Pagop präsentierten zunächst einmal die Konzepte von Rest, um dann anhand der Implementation von JBoss RESTEasy konkrete Implementierungsbeispiele zu geben. Der konzeptionelle Überblick war prägnant und unterhaltsam und hat mich überzeugt, diesen Architekturstil mindestens prototypisch einzusetzen. Die Beispielsession hätte meiner Meinung nach noch konkreter mit Edit-Compile-Run Zyklen durchgeführt werden sollen.

Bei einem WebService Modell werden die Objekte und ihre Zugriffsmethoden über WSDL/SOAP einem entfernten Klienten zur Verfügung gestellt. Es existieren Tools, um auf Basis der WSDL-Beschreibung clientseitige Stubs zu generieren und dann in der präferierten Programmiersprache auf die Ojekte im Server zuzugreifen. Es wird also das auf dem Server vorhandene Objektmodell mit den angebotenen spezifischen Operationen lokal im Client zugreifbar gemacht.

Ganz anders bei REST. REST wurde von Roy Fielding in seiner Doktorarbeit definiert. REST kann man im wesentlichen durch die folgenden 5 Merkmale beschreiben:

1. Jedes “Ding” bzw. jede Ressource hat eine ID
2. Die Resourcen werden über Links verknüpft.
   Der Server stellt dem Klienten die Verknüpfungen zwischen verschiedenen Ressourcen als Links zur Verfügung. Auch Statusübergänge werden als Link repräsentiert.
3. Es gibt standardisierte Methoden für alle Ressourcen
   • Get
   • Put
   • Post
   • Delete (und einige wenige andere)
4. Jede Ressource kann verschiedene Repräsentationen haben
   Es ist also möglich für verschieden Arten von Klienten unterschiedliche Repräsentationen nach außen zu geben: beispielsweise eine PDF-Repräsentation zum Drucken einer Rechnung und eine XML-Repräsentation zum Weiterleten der Teileliste an den Empfänger. Die benötigte Repräsentation wird zwischen Sender und Empfänger ausgehandelt. Selbst verschieden Versionen einer Ressource-Repräsentation können über diesen Mechanismus nach außen gegeben werden.
5. statuslose Kommunikation
   Eine Grundannahme ist, daß der Server keine Information über den Status des Klienten hält. Der Status eines Serverobjektes kann bzw. muß jederzeit wieder abgerufen werden können. Was der Klient jedoch damit macht, ob er eine URI bereits gelesen hat, ist Sache des Klienten und nicht des Servers. Es  gibt somit einen Ressourcenstatus, der im Server gespeichert wird, und einen Klientenstatus, den der Klient selbst speicher muß. Durch dieses Design kann der Server wesentlich besser skalieren.

Durch dieses einfache Modell,das in der HTTP Spezifikation festgelegt ist, können einheitliche und jedem bekannte Mechanismen für den Zugriff genutzt werden.Außerdem sind auch Fehlermeldungen mit einer festen Bedeutung vordefiniert und es ist möglich, für HTTP vorgesehene Cache- und Load-Balancing Mechanismen auch für den Zugriff auf den eigenen Backend-Server einzusetzen. Nicht zuletzt erlaubt es REST, den KLienten in jeder beliebigen Programmiersprache zu erstellen, für die eine HTTP-Client Bibliothek zur Verfügung steht.

Die REST Schnittstellen werden über Annotationen an bestehende Java Beans hinzugefügt.Die Annotationen beschreiben im wesentlichen den Pfad (die URI) einer Ressource und wie die öffentlichen Methoden mit auf Methoden der Objekte im Server und auf die Parameter dieser Methoden abbgebildet werden. Es bietet sich an, die Annotationen nicht in dem POJO selbst hinzuzufügen, sondern eine Ressourcenfassade einzuführen.

Stefan Tilkov präsentierte noch einen Ausflug zum Thema “asynchronous response handling“um aufzuzeigen, wie man in REST länger laufende Operationen oder Transaktionen modelliert. Auch hier hilft der HTTP Standard weiter: es gibt eine spezifische Antwort “202 accepted” die in einem solchen Fall zurückgegeben werden sollte. Sie zeigt an, daß die Bearbetung nicht abgeschlossen ist.Eine vom Klienten angegebene “Return URL” könnte vom Server aufgerufen werden, um sein Ergebnis zu posten.

Die Entscheidung für REST ändert definitiv die Architektur von Klient und Server, da nicht einfach das vorhandene Objektmodell über ein weiteres Protokoll zur Verfügung gestellt wird.Die wesentlichen Vorteile von REST sind, daß der Server einfach über einen Browser getestet werden kann und daß es einfach aus dynamischen Sprachen wie Ruby, JavaScript oder Python  genutzt werden kann.

Links

1. Fielding, Roy Thomas: Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000
2. Tilkov, Stefan:A Brief Introduction to REST . Online publication, Dec 10, 2007
3. RESTEasy, Online publication
4. Jersey, Online publication
5. Best practices for Web services versioning, Online publication
   Kyle Brown, Michael Ellis, IBM January 30, 2004
6. The REST Statelessness Constraint, Online Publication, Sat, 2009-Jun-13