REST-Grundlagen. Olga Liskin.

Transkript

1 REST-Grundlagen Olga Liskin Abstract: Das World Wide Web stellt mit seiner Größe und Heterogenität harte Anforderungen an Webbasierte Systeme. REST als Architekturstil hat das Ziel, zu helfen, bessere Web-basierte Systeme zu erschaffen, die die Technologien des Webs erfolgreich ausnutzen und an dem bisherigen Erfolg des World Wide Webs anknüpfen. Es werden zunächst abstrakte Bedingungen in REST definiert und dann zu Prinzipien für Web-basierte Systeme abgeleitet. 1 Einführung Representational State Transfer (REST) ist ein Software-Architekturstil für verteilte Hypermedia- Anwendungen. Roy Fielding hat in seiner Dissertation [1] den Begriff geprägt und gilt daher nach wie vor als Autorität auf diesem Gebiet. Er zeigt eine abstrakte und theoretische Sichtweise auf REST und die Thematik von Architekturstilen. Neben dieser Sichtweise hat sich eine zweite eher praxisorientierte Sichtweise etabliert, in der es um die Erzeugung von Systemen im World Wide Web geht, die sich an die Prinzipien des REST- Architekturstils halten und damit von seinen Vorteilen, wie der hohen Skalierbarkeit, profitieren. Diese Sichtweise ist insbesondere populär geworden, seit Web-Clients nicht mehr nur Webbrowser sind, die Daten einfach nur dem Menschen anzeigen, sondern auch andere Programme, die Daten weiterverarbeiten können und so ein Programmable Web geschaffen haben. 1 Gegenstand dieser Ausarbeitung ist es, REST aus beiden Perspektiven zu betrachten, sie zueinander in Verbindung zu setzen und ihre Problemstellungen und Lösungsansätze zu untersuchen. Das Ziel dieses Vorgehens ist es, ein allgemeineres Verständnis über REST herzustellen, als es in anderen Quellen, die sich nur auf eine Sichtweise beschränken, vermittelt wird. REST als Architekturstil hat als Ziel, zu helfen, bessere Web-basierte Systeme zu erschaffen, die die Technologien des Webs erfolgreich ausnutzen und an dem bisherigen Erfolg des WWW anknüpfen. Dies erreicht man in einem zweistufigen Prozess: 1. Identifikation der verantwortlichen Aspekte 2. Anwendung der Aspekte auf künftige Design-Prozesse. Der erste Schritt wird durch die abstrakte Sichtweise auf REST und dessen Constraints realisiert, wie in der Dissertation von Fielding [1]. Diese Sichtweise sowie die Ergebnisse dieses Schrittes werden in den Abschnitten 2 und 3 behandelt. Der zweite Schritt wird durch die konkrete Sichtweise mit den entsprechenden Prinzipien und Patterns für Web- Systeme realisiert und in Tilkovs [2] und Ruby und Richardsons [3] Veröffentlichungen verwendet. Diese Prinzipien werden in den Abschnitten 4 und 5 aufgegriffen. Während sich der erste Teil mit REST an sich beschäftigt, wird im zweiten Teil eine Transition zu RESTful HTTP und REST-konformen Systemen vorgenommen. Die Verbindung wird in Kapitel 3 aufgebaut. 2 Der Begriff Architekturstil REST ist ein Architekturstil. Um verstehen zu können, was REST genau ist, sollte man sich zunächst vor Augen führen, was genau ein Architekturstil ist und was dieser bezweckt. 1 Webservices im Programmable Web sind zum Beispiel der Amazon Simple Storage Service (Speicherung von Daten) oder über die Twitter API zugängliche Services (Mikroblogging). Weitere finden sich auf

2 Beginnen wir mit dem Begriff Architektur. Es gibt keine offizielle Definition, was auch zur Folge hat, dass der Begriff unterschiedlich verwendet wird. Roy Fielding [1] definiert Architektur in Bezug auf Netzwerk-basierte Software als Abstraktion der Laufzeit-Elemente eines Systems innerhalb einer Operationsphase des Systems. Ein System kann verschiedene Abstraktionsebenen und verschiedene Operationsphasen haben, von denen jede eine eigene Architektur besitzen kann. Der wichtige Begriff in der Definition ist Abstraktion. Er zeigt auf, dass eine Architektur ein System beschreibt, indem sie es abstrahiert, also bestimmte Aspekte des Systems herausstellt und andere (hinter der Abstraktion) versteckt. Architekturen bestehen aus Komponenten und Verbindungen zwischen diesen. 2 Zusätzlich sollte eine Architektur laut Fielding [1] auch Art und Bewegung von Datenelementen beschreiben, da dies ein wichtiger Aspekt ist, um Architekturstile hinreichend voneinander unterscheiden zu können. Im Bereich der Software sind Komponenten laut Fielding [1] abstrakte Einheiten von Instruktionen, die eine Schnittstelle bereitstellen um Daten zu transformieren. Indem man vorgibt, welche Komponenten auf welche Art in einer Architektur miteinander verbunden sind und welche Datenelemente sich bewegen (Constraints), induziert man Eigenschaften (Properties), die mit der Architektur verbunden sind. So kann ein Constraint also, angewandt auf ein, eine Architektur auf diesem System mit bestimmten Eigenschaften definieren. Insbesondere können auch mehrere Constraints zusammen in Wechselwirkung Eigenschaften erzeugen. Nun kann man eine Menge von Constraints die gut zusammen passen und einen bestimmten Zweck erfüllen, gruppieren. Diese Zusammenfassung heißt dann Architekturstil. Es scheint zunächst verwirrend, eine Menge von Elementen (hier: Constraints) Stil zu nennen. Der Grund hierin liegt in dem Zweck von Architekturstilen, verschiedene Architekturen zu kategorisieren. Da es an sich schwierig ist, Architekturen miteinander zu vergleichen, können so Architekturen, die bestimmte Eigenschaften erfüllen, dem gleichen Architekturstil angehören. Insbesondere Muster, die immer wiederkehren, kann man so gut verpacken. Eine Architektur ist eine Instanz eines Architekturstils, wenn sie bestimmte Constraints erfüllt. Insbesondere kann eine Architektur mehreren Architekturstilen angehören, wenn sie die Constraints aller dieser Architekturstile erfüllt. Als Resultat der Angehörigkeit zu einem Architekturstil, lassen sich Aussagen über Eigenschaften (induziert durch erfüllte Constraints) der Architektur treffen. Ein Beispiel für einen Architekturstil ist der Client-Server-Stil. Eine Architektur, die dem Client-Server-Stil folgt, besteht aus zwei Komponenten, einer Server Komponente, die Dienste anbietet und auf Anfragen bezüglich der Dienste wartet (lauscht) und einer Client-Komponente, die, wenn sie möchte, dass einer der Dienste ausgeführt wird, eine Anfrage an die Server-Komponente sendet. Dies sind Constraints des Stils. Weitere Constraints sind, dass User-Interface-bezogene Funktionalität vom Client gehandhabt wird, während der Server Datenmanagement-Funktionalität übernimmt. Ein Software-Engineering-Prinzip, das hinter diesen Constraints steht, ist Separation of Concerns. Die Eigenschaften, die mit einer Client-Server-konformen Architektur verbunden sind, sind Skalierbarkeit, Einfachheit und unabhängige Entwickelbarkeit sowie Austauschbarkeit der Komponenten. Eine konkrete Architektur, die diesen Stil befolgt, besteht zum Beispiel aus einem HTTP-Server, der HTTP-Nachrichten mit HTML-Repräsentationen von Webseiten liefert und verschiedenen Browsern, die als Clients fungieren und Webseiten anfordern. 3 Einbettung von REST Mit REST werden viele Dinge in Verbindung gebracht. Das kann daran liegen, dass eben nicht ganz klar ist, was REST genau bedeutet oder daran, dass REST ein populärer Begriff ist, der vorschnell verwendet wird. Dabei entsteht eine Verwirrung, in der nicht mehr unbedingt klar ist, was diese Dinge eigentlich sind und wie sie mit REST und untereinander zusammenhängen. In diesem Abschnitt sollen einige häufig gebrauchte Begriffe um REST aufgegriffen und beschrieben werden. In dieser Ausarbeitung wird eine Transition von dem abstrakten Begriff REST nach unten hin zu konkreteren REST-konformen Webservices durchgeführt. 2 Häufig dargestellt als Vierecke mit Kanten dazwischen.

3 3.1 REST REST selbst ist, wie in der Dissertation von Roy Fielding [1] vorgestellt, ein Architekturstil. Wie im vorigen Kapitel gezeigt, ist ein Architekturstil eine Sammlung von Regeln, welche dann von einer Architektur instanziiert werden kann, indem sich die Architektur an die Regeln hält. Insbesondere ist REST keine Architektur, sondern eine Sammlung von Regeln, die von konkreten Architekturen befolgt werden können. Ebenfalls wurde beschrieben, dass mit einem Architekturstil, bedingt durch die Regeln, bestimmte Eigenschaften verbunden werden. Das bedeutet hier, dass REST auch als Ziel hat, Architekturen hervorzurufen, die bestimmte Eigenschaften haben. Im Folgenden werden Regeln des REST-Stils sowie die von ihnen induzierten Eigenschaften beschrieben. Client-Server: Client-Server ist selbst ein Architekturstil, dessen Constraints und Eigenschaften in den REST- Architekturstil fließen. Wie auch schon in Abschnitt 2 beschrieben, besteht so eine Architektur aus zwei Komponenten, einer Server-Komponente, die Dienste anbietet und auf Anfragen bezüglich der Dienste wartet und einer Client-Komponente, die, wenn sie möchte, dass einer der Dienste ausgeführt wird, eine Anfrage an die Server-Komponente sendet. Eine Architektur, die diesem Stil folgt, hat als Eigenschaften unter Anderem, dass 1. die Benutzeroberfläche, die vom Client gehandhabt wird, portabel ist, 2. das System skalierbar ist, da die Server-Komponente simpel gehalten ist und 3. beide Komponenten unabhängig voneinander entwickelt werden können, solange sie sich an das festgelegte Interface halten. Stateless: Client-Stateless-Server ist wiederum ein Architekturstil, vorgestellt von Fielding [1], dessen Eigenschaften in den REST Stil einfließen. Dieser Stil besagt, dass Anfragen, die vom Client an den Server gesendet werden, alle Informationen enthalten, die der Server zum Abarbeiten der Anfrage benötigt. Somit muss der Server selbst keine Informationen über den Anwendungszustand des Clients merken und bereithalten. Die Anwendung dieses Stils bewirkt, dass die Skalierbarkeit noch weiter steigt, da die Server-Komponente weniger belastet wird und nun zwei aufeinander folgende Anfragen auch von unterschiedlichen Servern ohne Schwierigkeiten abgearbeitet werden können. (Man kann also, indem man die Servermenge z.b. verdoppelt, auch die Kapazität des Systems verdoppeln.) Ein Nachteil ist die höhere Netzwerkbelastung, da Daten möglicherweise mehrfach übersendet werden müssen. Cache: Cache-Constraints (wieder aus einem entsprechenden Architekturstil in Fieldings Dissertation [1]) fordern, dass Antworten auf Anfragen, die vom Server an den Client übermittelt werden, explizit als cache-bar oder nicht-cache-bar deklariert werden und der Client entsprechend durch Cachen der Antwort reagiert und für spätere äquivalente Anfragen die gecachte Version verwenden darf. Da hiermit der Client in entsprechenden Fällen Anfragen an den Server vermeidet, wird das Netzwerk-Aufkommen reduziert, was zu einer Entlastung des Servers und zu schnelleren Bearbeitungszeiten auf dem Client (durch Vermeidung von Latency durch Netzwerk-Kommunikation) führt. Ein Nachteil ist, dass die Verlässlichkeit sinken kann, wenn sich die gecachte Version sehr von der aktuellen Version auf dem Server unterscheidet. Uniform Interface: Das Kernelement, das REST von anderen Netzwerk-basierten Architekturstilen, wie zum Beispiel den eben vorgestellten, unterscheidet, ist die Forderung nach einer einheitlichen Schnittstelle in allen Komponenten. Können alle Komponenten über die gleiche Schnittstelle angesprochen werden, so vereinfacht dies die allgemeine Systemarchitektur und entkoppelt Services von ihrer Implementierung, was wieder eine hohe Austauschbarkeit zufolge hat und ermöglicht, die Komponenten unabhängig voneinander zu entwickeln. Ein Nachteil ist, dass Effizienz sinkt, da es keine auf die Anwendung zugeschnittenen Methoden mehr gibt. Um das Uniform Interface umzusetzen, müssen mehrere Interface-Constraints erfüllt werden (Identifikation von Ressourcen, Repräsentation von Ressourcen, Selbsterklärende Nachrichten, Hypermedia as the Engine of Application State (HATEOAS)), welche sich in den Prinzipien in 4. wiederfinden werden. Layered System: Der Layered-System-Stil (Fielding [1]) besagt, dass jede Komponente nicht hinter die Schicht von Komponenten, mit denen sie direkt verbunden ist, blicken kann. Hiermit wird eine mehrschichtige hierarchische Architektur erlaubt, in der zwischengeschaltete Komponenten Requests von Clients an Server oder andere zwischengeschaltete Komponenten weitergeben können. Dies ermöglicht einen besseren Lastenausgleich, indem Anfragen an bestimmte Server weitergeleitet werden können, die gerade weniger belastet sind als andere. Außerdem wird verteiltes Caching ermöglicht, bei dem verschiedene Clients, die eine äquivalente Anfrage stellen, eine gecachte Version von einem Proxy-Server erhalten können. Durch diese Aspekte kann die Skalierbarkeit eines Systems auf Web-Größe erhöht werden.

4 Code on Demand: Dieser Constraint ist optional. Er besagt, dass Clients durch Laden und Ausführen von Plug- Ins und Code-Fragmenten erweitert werden können. Das macht die Client-Komponente erweiterbarer, kann jedoch die Transparenz, die eine Eigenschaft des Stateless-Constraints war, beeinträchtigen, da sich nun verschiedene unsichtbare Aktivitäten hinter einem einzelnen Request verbergen können. Zusammenfassung: Constraint Vorteile Nachteile Client-Server Skalierbarkeit, Einfachheit, Entwickelbarkeit der Komponenten Stateless Skalierbarkeit, Einfachheit, Transparenz Höheres Netzwerkaufkommen Cache Effizienz, Skalierbarkeit Risiko Verlässlichkeit Uniform Interface Einfachheit, Skalierbarkeit, Entwickelbarkeit Geringere Effektivität Layered System Effizienz, Skalierbarkeit, Einfachheit, Entwickelbarkeit Code on Demand Effizienz, Skalierbarkeit, Entwickelbarkeit, Erweiterbarkeit Zusammenfassung der REST-Constraints und derer Eigenschaften Risiko Transparenz 3.2 RESTful HTTP REST, als Sammlung von Regeln und daraus resultierenden Eigenschaften, ist zunächst ein abstrakter Architekturstil, der durch Architekturen in verschiedensten Umgebungen instanziiert werden kann. Dennoch steht REST in engem Zusammenhang mit dem Web als Umgebung. Fielding selbst hat an vielen Web- Protokollen und Standards mitgearbeitet und definiert REST dann auch in Bezug auf verteilte Hypermedia- Systeme (Fielding [1]). Man könnte auch sagen, REST formalisiert die Architektur des Webs und stellt die wichtigen Richtlinien sowie deren Zweck heraus. Die Features, die durch Einhaltung des REST-Stils bewirkt werden, sind gerade die, die für den immens weiträumigen Erfolg des World Wide Web verantwortlich sind. Heutzutage ist außerdem die Architektur des Webs die einzige relevante Instanz von REST (Tilkov [2]). Wie genau hängen nun Web und REST zusammen? Das World Wide Web ist ein großes System von miteinander vernetzten Komponenten. Ich möchte hier das World Wide Web in Teilsysteme zerlegen und diese in Hinblick auf REST betrachten. Ein Teilsystem besteht aus einigen Komponenten, die (über HTTP) in die Plattform Web eingebettet sind und derart miteinander verbunden sind, dass sie ein System für sich bilden. Ein Teilsystem kann beispielsweise aus Servern, die einen bestimmten Service, wie das Hosting von Dateien, anbieten, und Clients, die diesen Service nutzen wollen, bestehen. Anstatt die Architektur des ganzen großen Webs zu betrachten, möchte ich die Architekturen von solchen Teilsystemen untersuchen. Verschiedene Teilsysteme können verschiedene Architekturen implementieren und es gibt solche, die dem Architekturstil REST folgen, aber auch welche, die dies nicht tun. Wenn ein Teilsystem eine Architektur hat, die eine Instanz des REST Stils ist, so nennt man dieses Teilsystem REST-konform. Der Begriff RESTful HTTP bezieht sich nun auf Teilsysteme im Web, die REST-konform sind. Er soll diese Teilsysteme gegenüber nicht-rest-konformen abgrenzen und zeigen, dass HTTP auch auf nicht-restkonforme Art verwendet werden kann (auch wenn es das eigentlich nicht sollte). RESTful HTTP konkretisiert REST, indem es den abstrakten Prinzipien konkrete Technologien gibt. 3.3 RESTful Webservices Das Web folgt dem Client-Server-Architekturstil. Client-Komponenten senden Anfragen an Services, die von Server-Komponenten angeboten werden. Daher bilden sich Teilsysteme im Web oft um Services im Web herum. Hierbei ist der Begriff Webservice von dem in Zusammenhang mit SOAP-RPC-Systemen gängigen Webservice-Begriff zu unterscheiden. Als Service gilt hier alles, was als Dienst von einem HTTP-Server über eine Schnittstelle angeboten wird. Die einfachste Form von Webservice ist eine Webseite. Ein Client, hier ein Browser, sendet eine Anfrage an den Server, ihm die Webseite zu liefern. Die Bereitstellung der Webseite vom Server an den Client ist somit ein Service. Der Begriff RESTful Webservice bezeichnet solche Webservices, die ein Teilsystem bilden, das REST-konform ist und ist dem Begriff RESTful HTTP relativ ähnlich. RESTful Webservices können also als Repräsentanten von REST-konformen Teilsystemen gesehen werden und sollen fortan Bezugspunkt sein.

5 3.4 Resource-Oriented Architecture Richardson und Ruby [3] stellen die Resource-Oriented Architecture (ROA) als Hilfsmittel vor, um Webservices REST-konform zu gestalten. Diese Architektur greift Prinzipien für RESTful Webservices auf, wie wir sie in Kapitel 4 sehen werden, und gibt in einem Prozess an, wie man Technologien rund um HTTP verwenden kann, um diese Prinzipien umzusetzen. Im weiteren Verlauf wird nicht gesondert auf dieses Thema eingegangen, es wird hier aber der Vollständigkeit halber aufgelistet. 3.5 Webservices über SOAP oder XML-RPC Oft wird REST den Begriffen SOAP oder XML-RPC gegenübergestellt. Hierbei ist vor allem zu erwähnen, dass dies grundsätzlich verschiedene Dinge sind, die nicht ohne Weiteres miteinander verglichen werden sollten. Während REST ein Architekturstil ist, der aus Regeln und Eigenschaften für Architekturen besteht, sind SOAP und XML-RPC (sowie der gesamte WS-* Stack) Netzwerkprotokolle, die angeben, wie Nachrichten im Netzwerk übermittelt werden sollen, sodass Webservices aufgerufen werden können. Was man vergleichen kann, sind Aufrufe von REST-konformen Webservices im Gegensatz zu Aufrufen von Services über das SOAP- Protokoll und die anschließende Übermittlung von Antwortnachrichten. Beispielsweise ist SOAP protokollunabhängig aufgebaut, was dazu führt, dass Webservice-Aufrufe immer mit der gleichen Methode (z.b. HTTP-POST) an den gleichen Endpoint gesendet werden und sämtliche Informationen im Entity-Body enthalten. REST-konforme Webservices hingegen sind auf das HTTP-Protokoll ausgelegt und werden über verschiedene HTTP-Methoden aufgerufen, die auch an verschiedene Endpoints gesendet werden. Beide Ansätze haben in verschiedenen Anwendungsszenarien ihre Vor- und Nachteile. Man kann jedoch gerade wegen ihrer Verschiedenheit nicht sagen, dass das eine besser sei als das andere. REST-Vertreter wie Richardson und Ruby [3] zeigen, dass Services im World Wide Web von der Einhaltung der REST-Prinzipien durchaus profitieren können und sich REST als ernstzunehmender Ansatz eignet. 4 Prinzipien REST-konformer Webservices In diesem Abschnitt ändert sich die Sichtweise auf REST. Während der erste Teil der Arbeit die abstrakten Eigenschaften von REST und REST-konformen Architekturen beschrieb, sollen die weiteren Abschnitte untersuchen, wie konkrete Webservices REST-konform entworfen werden können. Zunächst soll hier die Funktionsweise von Client-Server-Kommunikation über HTTP beschrieben werden. Client und Server kommunizieren über Mitteilungen miteinander. Ein Client sendet dem Server einen HTTP- Request, eine Anfrage nach einem Dienst. Ein vereinfachter HTTP-Request hat die folgende Form: 3 GET /index.html HTTP/1.1 Host: Accept: text/xml, text/html Accept-Language: en Hierbei ist GET die HTTP-Methode, die angibt, was der Server tun soll, /index.html der Pfad zur Ressource, an der die Methode ausgeführt werden soll. Dann folgen Request-Header, die Meta-Daten über den Request bereitstellen, wie zum Beispiel Accept, was angibt, welche Dateiformate der Client in der Antwort erwartet. Anschließen folgt der Entity-Body, in dem gegebenenfalls zusätzliche Informationen als Parameter für den Request enthalten sind. In diesem Fall ist der Entity-Body leer, da für den GET Befehl keine weiteren Parameter benötigt werden. Eine entsprechende HTTP-Response kann dann folgendermaßen aussehen: HTTP/ OK Last-Modified: Sun, 25 Apr :02:02 GMT Content-Type: text/html <html> <head><title>example</title> 3 Die komplette Syntax mit allen möglichen Headern und Response-Codes kann im HTTP Standard [5] eingesehen werden.

6 </html> Die Nachricht besteht aus einem Response-Code (200 OK), der angibt, von welcher Art die Response ist. Dann folgen Response-Header, wie, dass die Antwort im HTML Format ist, und schließlich der Entity-Body, der hier das HTML-Dokument enthält. In einem REST-konformen Webservice müssen Request und Response den Constraints aus 3.1. genügen. Wie eine Architektur beschaffen sein muss, um das zu können und wie sie die Technologien des Webs dafür ausnutzen kann, wird durch die Prinzipien in den folgenden Unterkapiteln verdeutlicht. Anhand eines durchgängigen Beispiels, das in jedem Teilkapitel aufgegriffen wird, sollen diese Prinzipien veranschaulicht werden. 4.1 Ressourcen als Grundlage des Systems REST-konforme Architekturen drehen sich um Ressourcen. Die interessante Information in einem System wird zu Ressourcen abstrahiert, wie in Fieldings Dissertation [1] beschrieben. Jedes Objekt, das für einen Client interessant sein kann oder die er anfordern wollen könnte, wird daher in einer Ressource gekapselt. Um ein REST-konformes System zu konstruieren, muss man in Ressourcen denken und das System um diese Ressourcen herum aufbauen (im Gegensatz zu z.b. Funktionen). Man braucht die Ressourcen, um die weiteren Prinzipien des Architekturstils verwirklichen zu können. Insbesondere dienen Ressourcen der Verwirklichung des Uniform Interfaces. Wenn man alle Objekte nur auf die gleiche generische Art ansprechen kann, so muss jedes interessante Objekt als Ressource bereitgestellt werden. Beispiel: Es soll ein Service erstellt werden, der einen verteilten Notizblock bietet. Benutzer können darin Notizen ablegen sowie Notizen von allen Benutzern betrachten und kommentieren. 4 Man kann dieses System auf verschiedene Arten betrachten, zum Beispiel kann man sagen, dass man Dinge anlegen kann und Dinge kommentieren kann. Diese Sichtweise bezieht sich auf die Aktionen, die ausgeführt werden können. Ein einheitliches Interface für alle Objekte kann hierauf nicht erzeugt werden, da man beispielsweise die Aktion kommentieren auf Notizen anwenden kann, jedoch nicht auf Benutzer. Eine andere Sichtweise bezieht sich auf die Objekte bzw. Ressourcen, die in dem System vorhanden sind, wie Benutzer, Notizen und Kommentare. Diese Ressourcen kann man allesamt anlegen, betrachten, ändern und entfernen, was das gewünschte einheitliche Interface darstellt. Um sämtliche Aktionen mit dem (relativ generischen) einheitlichen Interface abzudecken, ist es notwendig, sämtliche Informationen, die interessant sein können, als Ressourcen erreichbar zu machen. Zum Beispiel könnte der Client an allen Notizen eines bestimmten Benutzers interessiert sein. Eine Methode, wie client.getallnotes() ist nicht möglich, da sie nicht dem einheitlichen Interface entspricht (comment.getallnotes() ergibt beispielsweise keinen Sinn). Stattdessen muss die Liste aller Notizen zu einem Benutzer als Ressource angeboten werden und kann dann mit der betrachten -Methode erreicht werden. 4.2 Identifikation von Ressourcen Wie eben erwähnt, ist jede Ressource ein Stück Information, welche irgendein Client erreichen wollen könnte. Damit ein Client dies tun kann, muss dieser die Ressource eindeutig identifizieren können. Im Web gibt es ein Konzept, das der globalen Identifizierung von Ressourcen dient, nämlich den URI (Uniform Resource Identifier). Ein URI ist eine Zeichenfolge, die nach einem bestimmten Muster aufgebaut ist. Dieses ist genauer im URI-Standard [4] beschrieben. Die Einhaltung eines einheitlichen Musters hat den Vorteil, dass fremde Benutzer das Muster verstehen und ohne weiteres verwenden können. URIs zur Identifikation von Ressourcen im Notizblock-Service sind zum Beispiel: der Benutzer oliskin eine Liste aller Notizen, die oliskin verfasst hat die siebente Notiz von oliskin alle Notizen im Notizblock alle Notizen, die das Schlüsselwort Video enthalten 4 Hauptsächlich soll das Beispiel auf sehr simple Art die vorgestellten Prinzipien verdeutlichen. Wer nach einem Nutzen für diesen Service sucht, kann sich zum Beispiel vorstellen, dass eine verteilter Kurs, z.b. beim Fernstudium, die sich gemeinsam ein Video im Unterricht anschaut, diesen Service nutzen kann, um Eindrücke der einzelnen Studenten zum Video zu sammeln und für alle bereitzustellen.

7 4.3 Verlinkung Wenn der Server dem Client als Antwort auf eine Anfrage ein Objekt bzw. die Repräsentation einer Ressource schickt, so kann diese, wie auch im normalen Web üblich, aus Hypermedien bestehen. Das wichtigste an Hypermedien ist die Verlinkung zwischen diesen. Wenn als Teil einer Repräsentation auf eine andere Ressource verwiesen wird, so kann der URI dieser Ressource als Identifikator angegeben werden. Ein Client (sei es ein Webbrowser im Auftrag einer Person oder ein Computerprogramm als Client) kann nun diesem URI folgen, um zu der Ressource an sich zu gelangen und weitere Informationen über diese zu erhalten. Das Prinzip der Verlinkung durch Hypermedien wird von Fielding [1] als Axiom für REST unter dem Namen Hypermedia as the Engine of Application State (HATEOAS) festgehalten und fordert, dass der Client sich durch Folgen von Links durch die Applikation bewegen können muss. Zum Beispiel enthält die Liste aller Notizen, die oliskin verfasst hat die einzelnen Notizen. Die Repräsentation sollte jedoch nicht nur die Bezeichnungen note01, note02, usw. erwähnen, sondern die Identifikatoren der zugehörigen Ressourcen usw. beinhalten. Wenn der Client eine derartige Repräsentation liest, kann er die richtigen Ressourcen anhand ihrer URI aufrufen und beispielsweise eine Repräsentation der Ressource in anfordern. Das entspricht dem Surfen im WWW durch Anklicken von Hyperlinks im Browser. 4.4 Repräsentationen von Ressourcen Eine Repräsentation einer Ressource ist die Darstellung dieser in einem bestimmten Format. Dabei muss die Repräsentation nicht unbedingt die gesamte Ressource komplett abbilden, sondern zeigt (aus Sicht des Service) relevante Informationen, die bestimmte Aspekte beschreiben (siehe Richardson und Ruby [3]). Repräsentationen dienen dazu, Informationen über Ressourcen auszutauschen. REST-Komponenten führen Aktionen auf Ressourcen aus, indem sie die Repräsentation dieser Ressourcen ändern. Nehmen wir als Beispiel die Ressource Benutzer. Wenn der Client von einem Server Informationen über die Ressource Benutzer oliskin anfordert, so erwartet der Client nicht, dass die physikalische Person, die der Benutzer ist, vom Server geliefert wird. Viel mehr ruft der Client Informationen um den Benutzer ab, die für ihn interessant sein können und den Benutzer beschreiben. Solche Informationen können Name und Benutzername des Benutzers, die Anzahl der verfassten Beiträge, die Liste der verfassten Beiträge oder das Datum der letzten Anmeldung sein. Da beispielsweise der Beruf oder die aktuelle Kleidung des Benutzers für den Notizblock- Service nicht relevant sind, tauchen diese Informationen über die Ressource nicht in Repräsentationen auf. Der Client muss die Antwort des Servers auf seinen Request (in Form einer Repräsentation) verstehen und verarbeiten können. Außerdem können verschiedene Clients verschiedene Arten von Repräsentationen benötigen. Die Vorgehensweise hier ist, verschiedene Repräsentationen einer Ressource auf dem Server bereit zu halten und den Client auswählen zu lassen, welche er haben möchte. Dies geschieht entweder durch bestimmte Header im HTTP-Request oder durch Kodierung in der URI. Ein Client könnte eine Repräsentation des Benutzers oliskin im XML-Format erhalten wollen. Je nach Service API, kann der Client dies zum Beispiel signalisieren, indem er den Request-Header Accept:application/xml setzt oder die Information in die URI codiert und die Ressource über /users/oliskin.xml aufruft. Als Repräsentation erhält der Client ein Dokument der Form <?xml version= 1.0 > <user> <name>olga Liskin</name> <username>oliskin</username> <notes> <note href= /> <note href= /> </notes> </user> Fragt der Client nach einem JSON-Dokument, so erhält er (falls dies unterstützt wird) ein Dokument der Form {user:

8 } {name: Olga Liskin, username: oliskin, notes: [{href: }, {href: } ] } Beide Dokumente haben den gleichen Inhalt, werden aber auf verschiedene Art dargestellt. Der User muss die entsprechende Repräsentation, die er erhält, verstehen und richtig parsen können. Repräsentationen müssen nicht immer den gleichen Inhalt haben, zum Beispiel ist auch denkbar, dass es eine Repräsentation des Benutzers im jpg-format gibt. Diese würde dann ein Foto des Benutzers darstellen. Auch hier existieren allgemeine Muster, die angeben, welche Tags für welche Elemente angegeben werden sollten. Will man beispielsweise Listen von Links angeben, so kann man das Atom Syndication Format (siehe ASF Standard [7]) oder auch einfach XHTML mit den <ul>, <li> und <a> Tags verwenden. Die Einhaltung solcher Muster macht Repräsentationen verständlicher. 4.5 Einheitliches Interface Wie schon in Abschnitt 3.1 beschrieben, sollen alle Services über ein einheitliches Interface angesprochen werden können. Für einen Service-Aufruf sind zwei Informationen notwendig, die Method Information und die Scoping Information, wie von Richardson und Ruby [3] vorgestellt. Die Method Information eines Web Service Aufrufes ist diejenige Information, die dem Server mitteilt, was genau er an dem Objekt tun soll (z.b. ändern, löschen, etwas berechnen). Die Scoping Information teilt mit, an welchem Element genau die Operation vorgenommen werden soll (z.b. Notiz 07 des Benutzers oliskin). HTTP bietet ein einheitliches Interface an, über das Webservices aufgerufen werden können. Der Client sendet einen HTTP-Request an den Server. Dabei wird die Method Information über sogenannte Verben in der HTTP Method des HTTP Requests (GET, PUT, DELETE, ) angegeben, die Scoping-Information wird in der URI festgelegt. Folgende Verben sind die gängigsten: GET: Informationen zur Ressource abrufen. HEAD: Wie GET, Informationen zur Ressource abrufen, jedoch wird der Entity-Body nicht übertragen. PUT: Eine Ressource (unter der angegebenen URI) anlegen oder die Ressource unter der URI aktualisieren. PUT wird zum Anlegen von Ressourcen verwendet, wenn der Client entscheidet, welche URI die neue Ressource haben wird. DELETE: Die Ressource löschen. POST: Eine untergeordnete Ressource anlegen oder Inhalt an das Ende einer Ressource hängen. POST wird zum Anlegen von neuen Ressourcen verwendet, wenn der Server entscheidet, welchen URI die neue Ressource haben wird. Der URI der neuen Ressource wird dem Client in der Response-Nachricht mitgeteilt. Einige dieser Verben haben laut HTTP Standard [5] bestimmte Eigenschaften. GET und HEAD sind sichere Methoden, was bedeutet, dass GET- und HEAD-Requests keine signifikanten Aktionen auf dem Server außer Abfragen auslösen dürfen. GET, HEAD, PUT und DELETE sind idempotente Methoden, was bedeutet, dass der Effekt nach mehrmaligem Absenden eines identischen Requests derselbe wie nach einmaligem Absenden dieses Requests sein soll. Ein Request enthält also stets eine HTTP-Method mit einer bestimmen Bedeutung und eine URI. Dies ist das einheitliche Interface an das sich alle Webservices halten sollten. Zum Beispiel können die verschiedenen Verben auf Ressourcen folgende Aktionen auslösen:

9 /users /users/oliskin /users/oliskin/notes URI GET PUT DELETE POST Zeigt Liste der Benutzer an n/a n/a n/a /users/oliskin/notes/note07 Zeigt Repräsentation von oliskin an Zeigt Liste der Notizen an Zeigt Repräsentation der Notiz 07 Legt Benutzer oliskin an oder aktualisiert dessen Daten n/a Aktualisiert Notiz 07 Löscht Benutzer oliskin n/a Löscht Notiz 07 n/a Fügt neue Notiz des Benutzers ein n/a Man beachte, dass neue Benutzer über PUT angelegt werden (da der Client die Bezeichnung und den URI von neuen Benutzern bestimmt) und neue Notizen über POST auf notes/ angelegt werden (da es in der Verantwortung des Servers liegt, eine Bezeichnung und URI für eine neue Notiz festzulegen). 4.6 Zustandslosigkeit Das Prinzip der Zustandslosigkeit (Statelessness) ist in Abschnitt 3.1 bereits beschrieben worden. Es besagt, dass alle Informationen, die der Server zum Abarbeiten eines Requests benötigt, in dem Request selbst enthalten sein müssen. Der Server speichert keine Informationen über den Anwendungszustand. Ein Indikator dafür, ob Client-Server-Kommunikation zustandslos ist, ist, auf welche Art man einer anderen Person eine bestimmte Ressource zeigen kann. Wenn man einfach die URI (z.b kopieren, dem anderen geben kann und dieser beim Aufruf die gleiche Information erhält, so ist die Anwendung zustandslos. Der Request (GET mit der URI) beinhaltet die ganze benötigte Information. Muss man dem anderen hingegen eine Beschreibung, wie gehe auf wähle Benutzer. Wähle dann den dritten Benutzer von oben und auf der folgenden Seite Notiz 7 angeben, weil es keine direkte URI gibt, so bedeutet dies, dass der Server in Abhängigkeit davon arbeitet, was der Client in vorhergehenden Requests angegeben hat, also den Anwendungszustand verfolgt. 5 Software-Engineering Praktiken für REST 5.1 Architektur-Patterns Zunächst lässt sich die Benutzung von Architekturstilen für den Entwurf allgemein als Software-Engineering- Praktik sehen. Verwendung von Architekturstilen im Entwurf kann als Verwendung von Patterns für Architekturen angesehen werden. Es werden Problematiken, Lösungen und Eigenschaften der Lösungen im Pattern vereinigt. Die Verwendung von Architekturstilen verbessert die resultierende Architektur, da sinnvolle Vorgaben für die Architektur definiert werden, was den Entwurf beschleunigt und hilft, Fehler zu vermeiden. 5.2 Patterns für Webservices Auch auf der konkreteren Ebene bei der Erstellung von REST-konformen Systemen lassen sich Patterns anwenden, um das Design zu verbessern. Beispiele für Patterns sind: Verwendung von Collection-Ressources: Sollen Kollektionen von Ressourcen abfragbar sein, wie zum Beispiel die Liste mit allen Notizen eines bestimmten Benutzers, so sollte man die Kollektion von Ressourcen als eigene Ressource bereitstellen, zum Beispiel über

10 Optimistische Transaktionen: Um bei konkurrierenden Modifikationen von Ressourcen durch verschiedene Clients keinen komplizierten Locking-Mechanismus implementieren zu müssen, kann man optimistische Transaktionen verwenden. Dazu sendet der Server mit einem Datenobjekt im Header ETag immer eine Zahl, die eine Version der Ressource kodiert. Für eine Modifikation stellt der Client eine Bedingte Anfrage, indem er den Header If-Match:{ETag} verwendet. Diese Anfrage wird vom Server nur abgearbeitet, falls die ETag-Version des Clients mit der des Servers übereinstimmt. Ansonsten sendet der Server eine Response der Art 412 Conflict zurück, was bedeutet, dass die Ressource seit der Version des Client verändert worden ist. 5.3 Anti-Patterns für Webservices Als Gegensatz zu Patterns werden auch Anti-Patterns vorgestellt, die signalisieren, dass ein Architektur-Design nicht gut in Hinblick auf REST-Konformität ist. Tilkov [6] stellt unter anderem die folgenden Anti-Patterns vor: Tunnelung von Methoden durch POST: Jede Anfrage wird durch einen POST-Request ausgeführt. Die eigentliche Methoden-Information wird im Entity-Body versteckt. Dies verstößt nicht direkt gegen die Regeln von REST, missachtet jedoch die Semantik der HTTP-Methoden und macht es schwieriger, Clients für dieses Interface zu schreiben. Solche Services können auch RPC-Charakter erhalten. Mangelnde Benutzung von Hypermedien: Wenn die Antworten, die der Server dem Client sendet, nur wenige Links enthalten, so verkommt der Service zu einer Art Web-based CRUD (Tilkov [6]), in der der Client Operationen auf Ressourcen durch Senden von Anfragen an URIs ausführt, sich jedoch nicht durch Nutzung von Links durch die Applikation hangeln kann. Dies verstößt gegen das Prinzip Hypermedia as the Engine of Application State. Wie dieser Name andeutet, können Hypermedien dazu beitragen, einen Anwendungszustand aus Sicht des Clients zu erzeugen, sodass der Client, ähnlich wie beim Surfen im Web, eine einzelne URI als Einstiegspunkt in die Anwendung benötigt und sich von dort aus wie durch eine Applikation bewegt. Ignoriert man das, so verfällt viel von dem Potenzial, welches ein Webservice besitzt. 6 Zusammenfassung In dieser Ausarbeitung wurde in zwei Schritten gezeigt, wie der Architekturstil REST und daraus ableitbare Prinzipien verwendet werden, um gute Web-basierte Systeme zu erstellen, die unter anderem Eigenschaften wie gute Skalierbarkeit und Austauschbarkeit der Komponenten haben. Dazu wurde REST von verschiedenen Perspektiven aus beleuchtet, um ein umfangreiches Verständnis zur Thematik herzustellen. Das Ergebnis des Vorgangs sind Patterns und Prinzipien zur Erstellung und Evaluierung von Web-Systemen, die aufzeigen, wie die Web-Technologien gut verwendet werden können. Die Aufstellung und Verwendung von Patterns ist eine wichtige SE-Praktik, die hier dazu verwendet wird, wiederkehrende Muster und Erfahrungen zu kapseln. Als nächster Schritt zur weiteren praxisorientierten Einführung in REST müsste nun konkret gezeigt werden, wie Programme geschrieben werden können, die Clients und Server im Web-System darstellen und wie diese Programme HTTP-Requests bzw. Responses absetzen und Nachrichten, die in den Entity-Bodies gesendet werden, verarbeiten können. (Insbesondere wären auch bereits vorhandene Service APIs mit deren Eigenschaften in Hinblick auf REST-Konformität zu betrachten.) Ein Problem das hierbei offen bleibt, ist, dass so geschriebene Programme eine sehr geringe Abstraktionsstufe besitzen, da sie auf dem Level von HTTP- Anfragen arbeiten. Frameworks sind daher ein wichtiges weiteres Mittel, um die Entwicklung von Clients und Servern (bzw. Services) zu abstrahieren und weiter zu verbessern. Leider sprengen diese Themen den Rahmen der Arbeit. Es sei an dieser Stelle an das Buch von Richardson und Ruby [3] verwiesen. Literaturverzeichnis [1] Fielding, R: Architectural Styles and the Design of Network-based Software Architectures. University of California, Irvine, [2] Tilkov, S: A Brief Introduction to REST. (Stand: ) [3] Richardson, L; Ruby, S: RESTful Web Services. O Reilly [4] URI Standard RFC (Stand: ) [5] HTTP 1.1 Standard RFC (Stand: ) [6] Tilkov, S: REST Anti-Patterns. (Stand: ) [7] Atom Syndication Format Standard RFC (Stand: )