RESTful Web Services

RESTful Web Services

Stefan Marr

Abstract .Der REST-Architekturstil und der Representational State Transfer als Basis für das Design von Web Services werden vorgestellt. Als Heranführung werden die Grundlagen für inter- operable Schnittstellen behandelt, welche an HTTP als eine Implementierung konkretisiert werden, um darauf aufbauend die vier wesentlichen Fragen und acht notwendigen Prinzipien zur konkreten Erstellung eines RESTful Web Services an einem Beispiel zu verdeutlichen. Darüber hinaus werden kurz Ansätze zur Lösung gängiger Probleme angerissen, um anschließend auf Vorteil des REST-Architekturstils insgesamt einzugehen und damit ein Fazit zu ziehen.

Index Terms .Interoperabilität, REST, Systemarchitektur, Web Services

I. EINLEITUNG

DER Wunsch nach Interoperabilität zwischen verschiede- nen Systemen hat in den letzten Jahren zur verstärkten Entwicklung sogenannter Web Services geführt. Wobei hier in der überwiegenden Mehrzahl Software entwickelt wurde, welche auf XML-Techologien aufsetzt und SOAP als Nach- richtenprotokoll einsetzt, um mit verschiedensten Systemen Daten auf einfache Art und Weise austauschen zu können.

Mit der Zeit zeigt sich jedoch immer mehr, dass auch mit diesem technologischen Ansatz nicht alle Probleme gelöst werden können, sich weitere, neue Probleme ergeben und die Komplexität der Gesamtsysteme insgesamt steigt, ohne jedoch das eigentliche Ziel, echte Interoperabilität, zu erreichen.

In seiner Doktorarbeit [1] aus dem Jahr 2000 formulierte R. T. Fielding einen Architekturstil für verteilte Hypermedia- Systeme, genannt Representational State Transfer (REST), welcher anschließend von verschiedenen anderen aufgegriffen worden ist und seit dem als Ansatz für interoperablere Web Services propagiert wird.

Dieser Ansatz soll nun an dieser Stelle vorgestellt und an- hand eines Beispiels für den praktischen Einsatz aufbereitet werden. Im Anschluss daran werden noch einige weitere As- pekte sowie Vor- und Nachteile gegenüber einer auf SOAP aufsetzenden Architektur angerissen.

II. DER REST-ARCHITEKTURSTIL

A. Representational State Transfer

Wie bereits erwähnt, wurde der Begriff in [1] von R. T. Fielding geprägt. Ein Hauptaugenmerk wird bei diesem

Stefan Marr ist Student am Hasso-Plattner-Institut der Universität Potsdam, Deutschland (email: stefan.marr@hpi.uni-potsdam.de).

Architekturstil auf Resourcen gelegt. Diese können in einer oder mehreren Repräsentationen verfügbar sein und werden über URIs (Uniform Resource Identifiers) identifiziert. Dabei wird Ressource selbst als eine semantische Entität definiert, von der ihr Autor wünscht, identifizierbar zu sein, ohne einen speziellen Wert zu implizieren. Der Inhalt bzw. die Repräsen- tationen einer Ressource können sich so ändern, ohne dass der Identifikator, der URI, sich ebenfalls ändern muss.

Weiterhin handelt es sich grundsätzlich um eine Cli- ent-Server Architektur, wie sie für das Web üblich ist. Ein einfaches Beispiel ist in Abb. 1 dargestellt. Ein Server wird üblicherweise von vielen Clients genutzt, welche prinzipiell grundverschieden sein können. Darüber hinaus kann es ver- schiedene Zwischenknoten geben. In diesem Beispiel ist einmal nur ein einfacher Proxy-Server dargestellt. Die Archi- tektur könnte jedoch durch weitere Knoten ergänzt werden, seien es nun Systeme für Load-Balancing und Datenhaltung oder auch Zwischenknoten zum Anschluss von anderen komplexen Systemen.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1. Einfache Client-Server Architektur, wie im Web üblich mit ver- schiedenen Clients und optional dazwischen geschaltetem Proxy-Server

Der nächste wichtige Punkt in der REST-Architektur ist die Zustandslosigkeit der Server. Dies bedeutet, dass der Client bei einer Anfrage alle relevanten Daten zum Verarbeiten die- ser Anfrage explizit mitschicken muss. Idealerweise soll der komplette Session-Kontext beim Client liegen. Dies hat ver- schiedene Vorteile, unteranderem Skalierbarkeit, da der Server keine Daten verwalten muss, die über eine Anfrage hinausgehen.

Daraus folgt auch die Vorstellung, dass ein Client durch die Repräsentation einer Ressource in einen Zustand versetzt wird und Hyperlinks als Transitionen zwischen Zuständen angese- hen werden können. Somit kann die Traversierung einer durch Hyperlinks verbundenen Struktur als Ablauf in einem Auto- matengraphen interpretiert werden.

Um die Effizienz so einer Architektur zu steigern, werden Caches z.B. mittels Proxy-Servern verwendet. Dies setzt je- doch voraus, dass ein Server eine Antwort zu einer Anfrage so markiert, dass ein Cache entscheiden kann, ob er die Antwort zwischenspeichern darf oder nicht.

Ganz besonderer Wert wird in diesem Architekturstil auf die Schnittstellen zwischen Systemen gelegt. Diese sollen möglichst uniform und minimal sein, damit die Komplexität des Gesamtsystems nicht unnötig erhöht wird. Dazu nun mehr im folgenden Abschnitt.

B. Interoperable Schnittstellen

Die Verwendung von speziellen Technologien allein bringt einem System noch keine Interoperabilität mit anderen Syste- men, dazu gehört außerdem eine geeignete Architektur und auf Verteilung spezialisierte Schnittstellen. Dies ist auch einer der größten Kritikpunkte am SOAP-Ansatz, vonseiten der REST-Vertreter. SOAP [3] und die WSDL [4] selbst geben keinerlei Standards oder Anregungen vor, wie Schnittstellen gestaltet werden sollten, um möglichst interoperabel zu sein.

Allgemein gilt für Schnittstellen, die nicht prozesslokal ge- nutzt werden sollen, dass sie möglichst grobgranular zu gestaltet sind. Dazu im Gegensatz sollen prozesslokal ver- wendete Schnittstellen möglichst feingranular untergliedert sein und aus den Prinzipien der objektorientierten Program- mierung den bestmöglichen Nutzen ziehen.

Remote-Interfaces, also nicht prozesslokal genutzte Schnitt- stellen, sollten hingegen möglichst dienstorientiert entworfen werden. Dies bedeutet, dass sie nur Werte - im Sinne eines Data Transfer Objects . verwenden sollen, nicht jedoch direk- te Objekt-Referenzen, und seiteneffektfrei sind. Damit ermöglichen sie eine lose Kopplung und sind somit ein we- sentlicher Faktor für eine hohe Interoperabilität.

Ein weitere Punkt ist in diesem Zusammenhang die Perfor- mance von Remote-Interfaces. Diese wird durch grobgranulare Schnittstellen sehr begünstigt, da die Anzahl der verteilten Methodenaufrufe, gegenüber feingranularen Schnittstellen, deutlich reduziert werden kann.

Damit ist auch verbunden, dass die Aufrufparameter alle In- formationen beinhalten müssen, die zum Abarbeiten der Anfrage notwendig sind. Über diese Architektur wird also die Komplexität der Schnittstelle reduziert und in eine tiefere Schicht verlagert, wodurch man die Einheitlichkeit der nach außen angebotenen Schnittstelle erreicht.

Dieser Gedanke wird in Verbindung mit dem REST- Architekturstil nun soweit entwickelt, dass man eine Schnitt- stelle aus ressourcengenerischen Methoden spezifiziert. Ressourcengenerische Methoden haben eine eindeutige Se- mantik unabhängig von einer speziellen Ressource, wodurch Annahmen zu ihrer Wirkungsweise getroffen werden können, ohne die Ressource kennen zu müssen, auf die sie angewendet werden. Die Möglichkeit auf Grundlage partiellen Wissens Informationen abzuleiten ist sehr positiv im Sinne der Intero- perabilität, da es dadurch möglich wird Abläufe oder Zusammenhänge auch für unbekannte Systeme abzuschätzen und somit automatisierte Operationen auf deren Ressourcen vorzunehmen.

Die Anzahl solcher ressourcengenerischer Methoden muss prinzipiell nicht einmal beschränkt sein, jedoch zeigen unter anderem die Erfahrungen aus dem Datenbankbereich, dass für Operationen auf Daten vier universelle Methoden ausreichen, die sogenannten CRUD-Operationen ( Create . Retrieve . Upda- te . Delete .. Da im REST-Architekturstil jedoch allgemeiner von Ressourcen die Rede ist, scheint eine exakte Einschrän- kung auf bestimmte Methoden erst einmal schwierig.

Mittels der Theorie der Speech Acts lässt sich zeigen, wie in [5,6] ausgeführt wird, dass die Anzahl der nötigen Metho- den jedoch gering ist und sich so eine minimale sowie uniforme Schnittstelle spezifizieren lässt, mit der alle denkba- ren Anwendungsfälle von Geschäftstransaktionen modellieren werden können.

Neben der Interoperabilität der Schnittstellen bekommt noch ein weiterer Punkt im REST-Architekturstil zentrale Be- deutung, die Adressierbarkeit der Ressourcen. Grundannahme hier ist, dass es ein eindeutiges System geben muss, in dem alle Ressourcen direkt identifiziert werden können sollen. Ei- ne hierarchische Anordnung ist hierbei von Vorteil jedoch nicht Kern der Aussage. Ein sehr verbreitetes System zur di- rekten Adressierung stellt der URI-Namensraum bereit und mit dem in diesem Zusammenhang oft gebrauchten Hypertext Transfer Protocol (HTTP) .ibt es außerdem einen sehr ver- breiteten Standard, der sich dem REST-Architekturstil bedient, dazu mehr im folgenden Abschnitt.

C. Das HTTP-REST-Interface

Im HTTP .ind acht verschiedene Methoden definiert um einfache Abfragen, oder auch komplexere Operationen auf einem kompatiblen Server durchzuführen. Unter diesen Ope- rationen gibt es nun vier Spezielle, GET, POST, PUT und DELETE. Diese lassen sich zum einen eins zu eins auf die CRUD-Operationen abbilden (POST= Create . GET= Retrieve . PUT= Update . DELETE= Delete ., und zum anderen sind sie wie in [6] gezeigt vollständig im Sinne der Modellierbarkeit von Geschäftstransaktionen.

Damit bilden diese vier HTTP-Methoden eine geeignete minimale und uniforme Auswahl und lassen sich als Imple- mentierung des REST-Architekturstils verwenden.

Wie bereits erwähnt, muss für ein uniformes ressourcenge- nerisches Interface ein besonderes Augenmerk auf die Semantik und die Eigenschaften der Methoden gelegt werden. Im HTTP sind die Methoden wie folgt spezifiziert.

GET ist dafür gedacht, die Repräsentation einer Ressource abzufragen und soll nach[9] safe .nd idempotent .ein. Safe bedeutet in diesem Zusammenhang, dass durch den Aufruf einer sicheren Methode an einer Ressource, keinerlei weiter- reichende Wirkung hervorgerufen wird. Ein GET-Aufruf soll also keine weitere Bedeutung haben, als das Abfragen einer Ressource. Es soll z.B. nicht möglich sein, über einen GET- Aufruf Daten zu löschen, zu verändern oder gar einen Vertrag mit jemandem zu schließen. Unter idempotent versteht man, dass der Seiteneffekt für N > 0 identische Anfragen derselbe ist, wie der für eine einzelne Anfrage, abgesehen von Fehlern.

Mit POST wird in lose gekoppelter Art und Weise der Zu- stand auf einem Server verändert. Es werden mit dieser Methode z.B. bestehende Ressource um Kommentare ergänzt, ein Beitrag einer Gruppe von Artikeln hinzugefügt, eine Da- tenbank erweitert oder Daten aus einem Formular übermittelt.

PUT wird verwendet um bestehende Ressourcen an einem speziellen URI zu ändern, in dem ihr neuer Wert dort abgelegt wird oder um an einem bestimmten URI eine neue Ressource anzulegen. Grundsätzlich ist für das Erstellen einer neuen Ressource aus semantischen Gründen POST der PUT- Methode vorzuziehen, da in den wenigsten Fällen von vornhe- rein klar ist, welchen exakten Identifikator eine neue Ressource bekommen wird, wenn diese z.B. in eine Daten- bank eingefügt wird. PUT soll außerdem idempotent sein.

Mit DELETE wird der Server aufgefordert, eine Ressource zu löschen. Diese Methode soll ebenfalls idempotent sein.

III. ENTWURF EINES RESTFUL WEB SERVICES

A. Ein Bookmark Web Service

Um die abstrakte Beschreibung des REST-Architekturstils mit Leben zu füllen, wird an dieser Stelle exemplarisch ein Web Service für die Verwaltung von Bookmarks entworfen. Dieser Service ist dazu gedacht einzelne Bookmarks aufzu- nehmen, welche über Tags also Schlüsselwörter gruppiert werden können. Zusätzlich soll es die Möglichkeit geben ver- schiedene Gruppen von Bookmarks abzufragen, etwa zu einem speziellen Schlüsselwort oder von einem bestimmten Nutzer. Dabei soll besonders auf den in Abb. 2 dargestellten Unterschied zwischen dem Entwurf eines ressourcenorientier- ten Systems geachtet werden. Ziel eines RESTful Web Services ist es Ressourcen über URIs verfügbar zu machen und nicht Services über eine nachrichtenorientierte Schnitt- stelle.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2. Gegenüberstellung der ressourcenorientierten Sichtweise mit der nachrichten- bzw. RPC-orientierten Sichtweise auf ein System

B. Vier Fragen und acht Prinzipien

Für den Entwurf eines RESTful Web Services müssen die folgenden vier Fragen beantwortet werden:

1) Welche Ressourcen gibt es?
2) Welche Repräsentationen sind sinnvoll?
3) Welche Methoden werden von den einzelnen Ressourcen unterstützt?
4) Welche Status-Codes bzw. Fehler können zurückgegeben werden?

Mit dem Beantworten dieser Fragen erhält man die notwenigen Informationen für eine anschließende Implemen- tierung. Zusätzlich wurden in [12] acht Prinzipien

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3. Acht Prinzipien für RESTful Web Services nach [12]

identifiziert, an welche man sich halten sollte um effiziente und interoperable Web Services zu erhalten, die auch den se- mantischen Ansprüchen des REST-Architekturstils gerecht werden. Eine Übersicht über die Prinzipien ist in Abb. 3 zu finden. Im folgenden Abschnitt werden die Fragen durchgear- beitet und die Prinzipien allgemein erläutert, um sie dann jeweils auf den Bookmark Web Service anzuwenden.

C. MyBookmarkWebService

1) . Welche Ressourcen gibt es? .

Als erster Schritt ist zu klären, welche Ressourcen für einen Service benötigt werden. Anschließend werden diese konzep- tionellen Entitäten dahingehend untersuchen, ob es sinnvoll ist sie nach außen hin anzubieten, wie es Prinzip (1) vorsieht. Für einige Ressourcen ist dies z.B. entweder aus Sicherheitserwä- gungen oder Performanceaspekten heraus nicht sinnvoll.

Der nächste Schritt besteht nun darin, diese Ressourcen nach Prinzip (2) zu optimieren, also so zu strukturieren, detail- lierte Informationen erst auf eine direkte Anfrage zurück gegeben werden. Dies ist sinnvoll um die zu übertragende Datenmenge zu beschränken und redundante Übertragungen zu vermeiden. Diese Untergliederung sollte jedoch nicht zu feingranular werde, sondern es sollte ein gutes Mittel zwi- schen minimaler Anzahl von Anfragen und minimaler Datenmenge pro Anfrage gefunden werden.

Um nun die Ressourcen identifizieren zu können, muss ein Namensraum von URIs entwickelt werden, wobei Prinzip (3) zu beachten ist. Das HTTP-REST-Interface besteht aus Inter- operabilitätsüberlegungen aus den vier genannten Operationen und wie erwähnt, werden besonders an die GET-Operation zusätzlich Anforderungen gestellt, denn diese soll, sicher und idempotent sein.

Beim Entwerfen des Namensraums scheint es oft bequem zu sein, in Anlehnung an das unterliegende Objektmodell eine Art RPC-Stil zu verwenden und damit zusätzliche Semantik der GET-Operation hinzuzufügen, dies ist jedoch ausdrücklich zuvermeiden. Ob dies ein scheinbar ungefährliches http://.../getBookmark?id=4 oder ein offensichtlich problematischeres http://.../deleteBookmark?id=4 ist sei dabei erstmal nicht relevant. Als Regel gilt, zur Identifi- zierung von Ressourcen werden Nomen verwendet und keine Verben. Dass die zusätzliche Semantik große Probleme birgt,

TABELLE I

URI-NAMENSRAUM

Abbildung in dieser Leseprobe nicht enthalten

zeigt ein einfaches Beispiel. Unteranderem verlässt sich Google darauf, dass GET eine sichere Operation ist und parst so das Web. Sollte Google nun auf einen potenziell nicht ab- gesicherten Service treffen, der diese erweiterte GET- Semantik implementiert, ist es durch aus denkbar, wenn auch hoffentlich nicht realistisch, dass alle mühsam gesammelten Bookmarks mit einmal gelöscht werden. Daher sollte jegliche nicht [9] entsprechende Semantik vermieden werden.

Weiterhin gilt, dass Ressourcen selbst eindeutig ohne eine Query .n dem URI identifiziert werden können sollen, da Que- . ry .n [15] als die Zeichenkette definiert ist, welche hinter einem ?-Zeichen angegeben ist und Informationen beinhaltet, welche von der Ressource selbst interpretiert werden sollen und somit zur Ressourcenidentifikation nur die URI-Teile vor dem ?-Zeichen infrage kommen. Queries sollten immer dann verwendet werden, wenn die daraufhin erzeugten Ergebnisse nicht selbst als Ressource gewertet werden sollen.

Von Anfang an angewendet auf dieses Beispiel ergeben sich erst einmal die Ressourcen. Diese sind einzelne Book- marks, Sammlungen von Bookmarks, einzelne Schlüsselworte, Listen von Schlüsselworten, sowie die Nut- zerprofile als einzelne Ressourcen, welche z.B. Verweise auf die Sammlung von Bookmarks und verwendeten Schlüssel- worte des einzelnen Users enthalten können. Bis auf die einzelnen Schlüsselworte als eigenständige Ressource müssen in diesem Fall alle Entitäten nach außen zur Verfügung ge- stellt werden, um den Service realisieren zu können.

Um Prinzip (2) zu genügen, muss überlegt werden, welche Daten schrittweise bezogen werden sollen. Bei der Gestaltung der Bookmarksammlungen ist abzuwägen, ob diese nur Ver- weise auf konkrete Bookmarks enthalten sollen oder die kompletten Bookmarks. Erstere Variante wäre aus Performan- cesicht nachteilig. Die deutlich erhöhte Anzahl von Anfragen zum Ermitteln der Bookmarks ist nicht über die potenzielle Einsparung der Übertragungsmenge zu rechtfertigen, da die Metadaten eines Bookmarks im Allgemeinen sehr gering sind. Ein Gegenbeispiel dazu könnte eine Bestellung sein, die sich aus den üblichen Daten wie Liefer- und Rechnungsadresse sowie der Liste der bestellten Produkte zusammensetzt. In der Repräsentation dieser Bestellung sollten keine Produktbeschreibungen hinterlegt sein, sondern diese sollten idealerweise durch verfeinernde Anfragen abgefragt werden, da sie selten direkt benötigt werden und die Datenmenge der Beschreibung deutlich größer ausfallen kann.

Mit diesen Überlegungen und mit Hilfe von Prinzip (3) ist Tabelle I entstanden. Darin ist der gesamte URI-Namensraum spezifiziert, der für den Service benötigt wird. Die geschweif- ten Klammern kennzeichnen dabei Platzhalter, unter anderem für den Benutzernamen oder eine Bookmark-Id. all ist ein spezieller Benutzer, der alle am System registrierten Benutzer repräsentiert um von allen Bookmarks der Benutzer die 20 Neusten auswählen zu können.

2) . Welche Repr . ä . sentationen sind sinnvoll? .

Um die Möglichkeiten des uniformen Namensraums voll auszuschöpfen, bietet es sich an, die Ressourcen eines Ser- vices geschickt so zu verbinden, dass es möglich wird, ohne Zusatzinformationen den Dienst schrittweise in Anspruch nehmen zu können. Dies wird realisiert, in dem in den Reprä- sentationen der Ressourcen Links auf andere Ressourcen mit einem semantischem Zusammenhang eingebettet werden, wie es Prinzip (6) vorsieht. Dadurch wird explizit der Zusammen- hang zwischen den Ressourcen ausgedrückt und auch eine automatisierte auf partiellem Wissen über den Services ge- stützte Nutzung begünstigt.

Für die vier hier gewählten Ressourcenarten gilt es nun, un- ter Beachtung von Prinzip (6), geeignete Repräsentationen zu wählen. In [13] wird ein Format für Bookmarks beschrieben, welches die nötigen Eigenschaften für den angedachten Ser- vice mitbringt und somit als Grundlage dienen wird. Das Format wird hier selbst nicht noch einmal von Grund auf er- läutert, sondern es wird nur auf die für den Service nötigen Erweiterungen eingegangen. Genauere Informationen sind in der Spezifikation unter [13] zu finden oder in den Beispielen von [10], auf den dieser Beispiel-Service basiert.

Das Beispiel in Abb. 4 führt über die <metadata> Tags dem Standard eigene Erweiterungen zu, welche über das owner Attribut unterschieden werden können. Es wird über dieses Attribut die Art der im Tag hinterlegten Informationen angegeben. Die Metadaten mit der Identifikation xbel- ext/baseuri sind eingefügt worden, um dem Prinzip (6) Rechnung zu tragen, denn hier wird der URI des Bookmarks auf dem Server angegeben, über welche später z.B. Update-

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4. Beispiel für ein Bookmark im XBEL-Format

oder Löschoperationen möglich sind. Da die Bookmarks in diesem Format auch in der Repräsentation von Bookmark- sammlungen Verwendung finden, ist es somit auch aus einer Sammlung heraus möglich einzelne Bookmarks später zu ad- ressieren. Die zweite Erweiterung xbel-ext/tags wird verwendet um die dem Bookmark zugeordneten Schlüssel- wörter anzugeben.

Die Repräsentation einer Bookmarksammlung wird im sel- ben XBEL-Format angegeben, nur mit mehreren <bookmark>-Elementen unter dem <xbel>-Wurzelelement.

Für die Darstellung einer Liste von Schlüsselworten wird wie im Beispiel, eine einfache Sequenz von <tag>-Tags ver- wendet, welche zusätzlich in einem <tags>-Wurzelelement eingebettet ist.

Auf die Festlegung eines speziellen Formats für das Nut- zerprofil soll hier gänzlich verzichtet werden. Für eine eventuelle Implementierung sei jedoch an Links auf die Schlüsselwortlisten des Nutzers und natürlich die Bookmark- sammlungen erinnert.

3) . Welche Methoden werden von den einzelnen . Ressourcen unterst . ü . tzt?

Um diese Frage zu beantworten, macht sich eine tabellari- sche Auflistung gut. Als Erstes muss überlegt werden, welche Methoden auf die einzelnen Ressourcenarten anwendbar sein sollen, um sie anschließend geordnet nach den möglichen Me- thoden in die Tabelle eintragen zu können.

Dieses Vorgehen lässt sich aus dem Prinzip (4) ableiten und erhöht die Übersichtlichkeit beim Entwurf. Vollständig ausge- füllt beinhaltet die Tabelle somit eine komplette Beschreibung des Service-Interfaces und ist damit nicht nur ein Schritt zu einer vollständigen Dokumentation sondern auch Vorausset- zung für die Implementierung und spätere Nutzung des Web Services durch andere Clients.

Durch Zuordnung von URIs zu anwendbaren Methoden wird die Anwendung von Prinzip (5) erleichtert. An diesem Punkt wird die konzeptionelle Integrität des URI- Namensraums geprüft. Sind alle GET-Anfragen seiteneffekt- frei und führen sich nicht zu Modifikationen an den Ressourcen? Zum Beantworten dieser Frage sollten auch die Eigenschaften safe .nd idempotent .berprüft werden. Zur Identifikation von Seiteneffekten sei noch angemerkt, dass Mechanismen wie Logging auf dem Webserver in diesem Fall nicht als echter Seiteneffekt gezählt werden, da diese nicht die Datenbasis des Services selbst betreffen. Der Vollständigkeit halber sollten in diesem Schritt auch die anderen Methoden noch auf ihre semantische Korrektheit im Sinne von [9] ge- prüft werden.

Nach dem Ausfüllen von Tabelle II zeigt sich nun, dass durch ein geschicktes Design des URI-Namensraums für den Beispielservice, die aufgestellten Anforderungen ohne weite- res erfüllt sind und somit eine semantisch einwandfreie und damit interoperable Schnittstelle geschaffen wurde.

4) . Welche Status-Codes bzw. Fehler k . ö . nnen . zur . ü . ckgegeben werden?

Im HTTP .erden verschiedene Status-Codes für die wich- tigsten Situationen definiert und von diesen sollte möglichst gebrauch gemacht werden, um dem Interoperabilitätsgedan- ken Rechnung zu tragen, da besonders Fehler oft durch unterschiedliche Definitionen die Interoperabilität beeinträch- tigen, auch wenn die Schnittstelle an sich sauber implementiert wurde. Wenn der Server die Anfrage nicht in- terpretieren kann, ist z.B. der Status-Code 400 zurückzugeben oder falls Fehler bei der Abarbeitung auf dem Server auftreten der Status-Code 500.

Aber nicht nur Fehler sondern auch Erfolgsmeldungen soll- ten standardkonform verwendet werden. So sollte auf das Hinzufügen eines Bookmarks zu einer Sammlung z.B. mit dem Status-Code 201 reagiert werden und entweder der URI zurückgegeben werden, unter dem das neue Bookmark zu finden ist, oder die komplette Repräsentation des Bookmarks.

Eine detaillierte Auflistung und Beschreibung der standar- disierten Status-Codes ist in [9] Abschnitt 10 zu finden.

5) . Dokumentation

Ein häufig unterschätzter Aspekt ist die Dokumentation ei- nes Services. Prinzip (7) und (8) gehen daher explizit auf diesen Umstand ein. Die Repräsentationen der Ressourcen sollten immer in einem geeigneten Format spezifiziert werden, um einem Konsumenten die vollständige Nutzung zu ermögli- chen. Für XML-Daten bieten sich hier die gängigen Spezifikationssprachen an, aber auch bei Binärformaten sollte stets eine Spezifikation zur Verfügung gestellt werden, um die Nutzung zu vereinfachen.

Für die Beschreibung der Servicestruktur an sich, ist es ebenso sinnvoll eine im besten Fall auch maschinenlesbare

TABELLE II

METHODENZUORDNUNG

Abbildung in dieser Leseprobe nicht enthalten

Spezifikation zu erstellen. Dies kann z.B. über die WSDL geschehen, welche voraussichtlich in der kommenden Version 2.0 die Beschreibungsmöglichkeiten für RESTful Web Ser- vices weiter verbessert oder - dann aber nicht unbedingt maschinenlesbar - mittels eines für den Menschen aufbereite- ten Dokuments, z.B. als simple HTML-Seite.

Wie auf einer gängigen Internetseite sollte es auch für diese Services üblich sein, eine Eintrittseite bzw. Ressource zu er- stellen, welche die für den Service wesentlichen Ressourcen referenziert, so wird es möglich über einen einzigen URI den gesamten Service verfügbar zu machen.

IV. WEITERE EINSATZMÖGLICHKEITEN UND VORTEILE

A. Transaktionen in ressourcenorientierten Web Services

Für die Realisierung von komplexen Geschäftsabläufen ist es unerlässlich die ACID-Eigenschaften ( Atomicity . Consis- . tency . Isolation . Durability . garantieren zu können. Nun ist die Frage, ob RESTful Web Services konzeptionell so etwas wie einen Transaktionsmanager zulassen, wo eine der Haupt- grundsätze ja die Zustandslosigkeit - im Sinne der Vermeidung von anfrageübergreifenden Sessioninformationen - des Servers ist. Eine Möglichkeit der Modellierung wäre, die Ressourcen so zu gestallten, dass es nicht nötig wird Transaktionen über mehrere Anfragen hinweg zu unterstützen. Falls dies nicht möglich ist, wäre der folgende Ansatz eine mögliche Lösung.

Denkbar wäre eine Ressource im Sinne eines Transakti- onsmanagers, welcher Anträge auf Transaktionen verwaltet. Mittels einer Anfrage, die dem Transaktionsmanager einen Antrag übermittelt, ließe sich eine Ressource erstellen, welche über einen URI referenziert werden kann, die eine zusammen- hängende Transaktion repräsentiert. Operationen welche nun den ACID-Eigenschaften genügen sollen, können mit einer Referenz auf diese Transaktionsressource auf dem Server durchgeführt werden, bzw. ihre Repräsentationen auf dem Server abgelegt werden. Um die Transaktion abzuschließen, wird ein weiterer Antrag an die Transaktionsmanager- Ressource gestellt, über den das Commit .er Transaktion an- gestoßen wird. Abschließend kann die Transaktion beendet und die Transaktionsressource freigegeben werden.

B. Asynchrone Web Services

Für einige Arten von Services ist es wünschenswert eine zeitliche Entkopplung, zwischen dem Stellen der Anfrage und dem Erhalten einer Antwort darauf, realisieren zu können. Da HTTP .elbst dafür keine Mechanismen vorsieht, bleibt hier nur die Möglichkeit, den Serviceanbieter entweder in be- stimmten zeitlichen Abständen oder nach Vereinbarung auf Abarbeitung der Anfrage anzusprechen. Dies hat auch aus architektureller Sicht einige Vorteile. Durch dieses Vorgehen benötigt der Server selbst keinerlei Informationen über den Anfragesteller und muss auch keine Information oder Mecha- nismen verwalten, um sicherzustellen, dass die Antwort auch beim Anfragenden ankommt. Damit bleibt die Komplexität des Servers auch für asynchrone Ausführung von Anfragen auf der gleichen Höhe und zusätzlich vermeidet man Abhän- gigkeiten zu Schnittstellen, die eventuell anfragerbezogen sein könnten.

C. Direkt Adressierung im URI-Namensraum

Wie bereits angerissen ermöglicht die Verwendung des URI-Namensraums eine direkte Adressierung aller Ressour- cen. Wenn hier zusätzlich noch eine Beschränkung auf Identifikatoren unter dem HTTP .ingeführt wird, ermöglicht dies einen uniformen Umgang mit diesen Ressourcen über ein einziges Protokoll und damit prinzipiell weitreichender Inter- operabilität.

Dazu im Gegensatz steht die Verwendung von SOAP als Grundlage für ein Applikationsprotokoll. Über diesen Ansatz sind die Ressourcen des Services nicht mehr direkt über einen eindeutigen URI zugänglich, sondern es muss der Weg über eine SOAP-Ressource genommen werden, welche die eigent- lichen Ressourcen versteckt. Durch diese Maßnahme werden diese Ressourcen in einen eigenen Namensraum verlagert und somit eine direkte Adressierung deutlich erschwert, wenn nicht teilweise unmöglich gemacht, womit die Interoperabili- tät dieser Dienste, im Vergleich zu Diensten die einen gemeinsamen, den allgemeinen URI-Namensraum nutzen, eingeschränkt wird und dass obwohl die meisten SOAP-Web Service sich selbst dieses Vorteils bedienen und direkt über einen URI ansprechbar sind.

Ein weiterer Punkt für diese Form der Adressierung von Ressourcen ist das Discovery .roblem. Auf HTTP-REST .uf- bauende Web Services sind ohne weiteres über allgemeine oder spezialisierte Web-Suchmaschinen auffindbar und erfor- dern somit keine zusätzliche Technologie.

D. Standards und Sicherheitsaspekte

Bei der Verwendung von HTTP als eine REST Implemen- tierung, ergeben sich einige weitere Vorteile, so gibt es für die großen Problemfelder der Nutzerauthentifikation und Sicher- heit bereits Lösungen, die erprobt sind. Unter anderem verschiedene Verfahren zur Authentifikation z.B. über Zertifi- kate oder auch Verschlüsselung z.B. durch HTTP over TLS .

Des Weiteren ist es ohne weiteres möglich, auch nicht- XML Daten effizient zu übertragen, was bei SOAP, da es komplett XML-basiert ist, problematisch bzw. ineffizient ist, wenn man nicht z.B. SOAP with Attachments .utzen kann, weil dies nicht von allen Clients unterstützt wird.

Mit der Verwendung von HTTP in einem aus semantischer Sicht richtigen Sinne wird außerdem das Filtern und Loggen der Anfragen möglich, wie es für Webseiten seit Langem üb- lich ist. Tools für Monitoring-Aufgaben lassen sich ebenso weiter verwenden, ohne sie speziell anpassen zu müssen.

E. REST vs. SOAP

Die oben genannten Vorteile resultieren überwiegend aus der Tatsache, dass ein einziges universelles Protokoll mit einer eindeutig spezifizierten Schnittstelle genutzt wird.

Dahingegen ist SOAP deutlich im Nachteil, wenn es um In- teroperabilität geht. Der Hauptgrund dafür ist, dass SOAP im Eigentlichen nur ein Framework für applikationsspezifische Protokolle ist. Mit SOAP als Grundlage werden somit ver- schiedene eigene Protokolle spezifiziert, die für jeden Anbieter unterschiedlich sind. Dies schließt sämtliche Vorteile aus, die darauf basieren, dass es ein oder zumindest wenige gut verstandene, eindeutige Protokolle gibt. Darunter fallen nicht nur die Möglichkeiten, die Filter haben, welche auf Grundlage von HTTP arbeiten, sondern vor allem auch die integrativen Vorteile, da nicht nur ein Protokoll mit verschie- denen Ressourcen, sondern viele Protokolle mit potenziell vielen Ressourcen unterstützt werden müssen.

Ein weiteres in SOAP noch nicht gelöstes Problem ist die Integration der sich stets erhöhende Zahl von Standards, wel- che die Kompatibilität der SOAP-Implementierungen untereinander behindert. Unteranderem gilt dies für den kom- menden WS-Addressing Standard, welcher es ermöglicht Service-Endpunkte und Nachrichten zu adressieren. Genau dieses Problem resultiert aus der Verlagerung der Ressourcen in einen neuen Namensraum und wird von HTTP-REST deut- lich geschickter gelöst.

F. Integrationsaufwand bei Verwendung uniformer Schnitt- stellen

Allgemein ist der Aufwand zur Integration von n verschie- denen Knoten in einem Netz der Ordnung [Abbildung in dieser Leseprobe nicht enthalten]. Auch in einem auf einer REST-Implementierung aufsetzenden Netz ist dies a priori nicht anders als in Netz bei denen jeder Knoten über eine eigene Schnittstelle angesprochen wird, da die An- zahl der vorstellbaren Ressourcen für ein spezielles Problem weiterhin nicht eingeschränkt ist. Dies könnte nur durch Stan- dardisierung in diesem Problemfeld erreicht werden.

Allerdings gibt es Hypothesen, die besagen, dass der Ge- samtaufwand deutlich geringer ist als bei Systemen, die jeweils unterschiedliche Schnittstellen nutzen, was offensicht- lich nachvollziehbar ist, und sich dieser Gesamtaufwand deutlich in Richtung Ordnung O(n) bewegt und somit wesent- lich effizienter ist als gängige Integrationsstrategien auf SOAP Basis.

V. FAZIT

Der REST-Architekturstil beachtet viele grundsätzliche Punkte um die Interoperabilität von Systemen sicher zustellen schon im grundsätzlichen Design. So ist die Spezifikation einer uniformen und minimalen Schnittstelle, einer der we- sentlichen Schritte zum Erreichen dieses Ziels. Auf HTTP- REST aufbauende sogenannten RESTful Web Services sind somit relativ einfach zu integrieren, da sie alle über dasselbe Protokoll kommunizieren und nicht wie bei SOAP über je- weils eigene anwendungsspezifische Protokolle. Darüber hinaus entfällt beim Erstellen solcher Web Services der Auf- wand für die Spezifikation eines geeigneten und performanten Protokolls, da nicht nachrichten- sondern ressourcenorientiert entwickelt wird und das Protokoll durch HTTP bereits vorge- geben ist.

Ein weiterer wichtiger Faktor ist, dass RESTful Web Ser- vices in vollem Umfang von den für HTTP vorhandenen Technologien gebrauch machen können und es so für die meisten Probleme bereits Lösungen gibt. Seien dies nun Logging, Monitoring, Authentifizierung oder das Filtern von unerwünschten Operationen an einer Firewall.

Das Problem, des Integrationsaufwands, löst dieser Ansatz jedoch auch nicht vollständig. Dieser ist weiterhin der Ord- nung [Abbildung in dieser Leseprobe nicht enthalten], wenn auch tendenziell geringer als bei der Verwendung von nicht uniformen Schnittstellen.

LITERATUR

[1] Roy Thomas Fielding, „Architectural Styles and the Design of Network- based Software Architectures“ Ph.D. Dissertation, University of Califor- nia, Irvine, 2000, S. 76ff.

[2] M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, R. Stafford, Pat- . terns of Enterprise Application Architecture. .ddison Wesley, 2002.

[3] M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. F. Nielsen, SOAP Version 1.2, 2003, http://www.w3.org/TR/soap12/

[4] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, Web Services Description Language (WSDL) 1.1, 2001, http://www.w3.org/TR/wsdl

[5] Carlos E. Perez (2005, März). Why REST is Better - Part 2 - Contract Based Protocols, http://www.manageability.org/blog/stuff/why-rest-part-2/view

[6] Carlos E. Perez (2004, Juni). The RESTfulness of Speech Acts, http://www.manageability.org/blog/stuff/the-restfulness-of-speech- acts/view

[7] Carlos E. Perez (2005, März). Artikelreihe Why REST is Better, http://www.manageability.org/blog/stuff/rest-explained-in-code/view

[8] Eckhardt Holz, Script zur Vorlesung Softwarearchitektur, WS2005/06, Hasso-Plattner-Institut, Universität Potsdam

[9] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. RFC 2616: Hypertext Transfer Protocol - HTTP/1.1. Inter- net Engineering Task Force, Juni 1999.

[10] Joe Gregorio (2005, März). Show Me the Code http://www.xml.com/pub/a/2005/03/02/restful.html

[11]Paul Prescod (2002, September). Common REST Mistakes http://www.prescod.net/rest/mistakes/

[12]Roger L. Costello (2003, Januar). Building Web Services the REST Way http://www.xfront.com/REST-Web-Services.html

[13] Fred L. Drake, Jr. The XML Bookmark Exchange Language, CNRI, Reston, USA, Oktober 1998. http://pyxml.sourceforge.net/topics/xbel/

[14]Zitatsammlung verschiedener Autoren (2004, Mai). InterfaceGenericity http://rest.blueoxen.net/cgi-bin/wiki.pl?InterfaceGenericity

[15] T. Berners-Lee, R. Fielding, L. Masinter. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. Internet Engineering Task Force, Au- gust 1998.

[...]

---