Seminar Advanced Database Technology: RESTful Web Services

1

RESTful Web Services

Stefan Marr

Architekturstil auf Resourcen gelegt. Diese können in einer Abstract—Der REST-Architekturstil und der Representational oder mehreren Repräsentationen verfügbar sein und werden State Transfer als Basis für das Design von Web Services werden über URIs (Uniform Resource Identifiers) identifiziert. Dabei vorgestellt. Als Heranführung werden die Grundlagen für inter- wird Ressource selbst als eine semantische Entität definiert, operable Schnittstellen behandelt, welche an HTTP als eine von der ihr Autor wünscht, identifizierbar zu sein, ohne einen Implementierung konkretisiert werden, um darauf aufbauend speziellen Wert zu implizieren. Der Inhalt bzw. die Repräsen- die vier wesentlichen Fragen und acht notwendigen Prinzipien tationen einer Ressource können sich so ändern, ohne dass der zur konkreten Erstellung eines RESTful Web Services an einem Beispiel zu verdeutlichen. Darüber hinaus werden kurz Ansätze Identifikator, der URI, sich ebenfalls ändern muss.

zur Lösung gängiger Probleme angerissen, um anschließend auf Weiterhin handelt es sich grundsätzlich um eine Cli- Vorteil des REST-Architekturstils insgesamt einzugehen und ent-Server Architektur, wie sie für das Web üblich ist. Ein damit ein Fazit zu ziehen.

einfaches Beispiel ist in Abb. 1 dargestellt. Ein Server wird üblicherweise von vielen Clients genutzt, welche prinzipiell Index Terms—Interoperabilität, REST, Systemarchitektur, grundverschieden sein können. Darüber hinaus kann es ver- Web Services 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, I. EINLEITUNG seien es nun Systeme für Load-Balancing und Datenhaltung D ER Wunsch nach Interoperabilität zwischen verschiede- oder auch Zwischenknoten zum Anschluss von anderen nen Systemen hat in den letzten Jahren zur verstärkten komplexen Systemen.

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 Zustandslosigkeit der Server. Dies bedeutet, dass der Client werden. Im Anschluss daran werden noch einige weitere As- bei einer Anfrage alle relevanten Daten zum Verarbeiten die- pekte sowie Vor- und Nachteile gegenüber einer auf SOAP ser Anfrage explizit mitschicken muss. Idealerweise soll der aufsetzenden Architektur angerissen.

komplette Session-Kontext beim Client liegen. Dies hat ver- schiedene Vorteile, unteranderem Skalierbarkeit, da der II. DER REST-ARCHITEKTURSTIL Server keine Daten verwalten muss, die über eine Anfrage hinausgehen.

A. Representational State Transfer Daraus folgt auch die Vorstellung, dass ein Client durch die Wie bereits erwähnt, wurde der Begriff in [1] von Repräsentation einer Ressource in einen Zustand versetzt wird R. T. Fielding geprägt. Ein Hauptaugenmerk wird bei diesem 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- Stefan Marr ist Student am Hasso-Plattner-Institut der Universität Potsdam, Deutschland (email: stefan.marr@hpi.uni-potsdam.de).

Seminar Advanced Database Technology: RESTful Web Services

2

und somit automatisierte Operationen auf deren Ressourcen matengraphen interpretiert werden.

vorzunehmen.

Um die Effizienz so einer Architektur zu steigern, werden Die Anzahl solcher ressourcengenerischer Methoden muss Caches z.B. mittels Proxy-Servern verwendet. Dies setzt je-

prinzipiell nicht einmal beschränkt sein, jedoch zeigen unter doch voraus, dass ein Server eine Antwort zu einer Anfrage so

anderem die Erfahrungen aus dem Datenbankbereich, dass für markiert, dass ein Cache entscheiden kann, ob er die Antwort

Operationen auf Daten vier universelle Methoden ausreichen, zwischenspeichern darf oder nicht.

die sogenannten CRUD-Operationen (Create, Retrieve, Upda- Ganz besonderer Wert wird in diesem Architekturstil auf

te, Delete). Da im REST-Architekturstil jedoch allgemeiner die Schnittstellen zwischen Systemen gelegt. Diese sollen

von Ressourcen die Rede ist, scheint eine exakte Einschrän- möglichst uniform und minimal sein, damit die Komplexität

kung auf bestimmte Methoden erst einmal schwierig.

des Gesamtsystems nicht unnötig erhöht wird. Dazu nun mehr

Mittels der Theorie der Speech Acts lässt sich zeigen, wie im folgenden Abschnitt.

in [5,6] ausgeführt wird, dass die Anzahl der nötigen Metho- B. Interoperable Schnittstellen den jedoch gering ist und sich so eine minimale sowie

Die Verwendung von speziellen Technologien allein bringt uniforme Schnittstelle spezifizieren lässt, mit der alle denkba-

einem System noch keine Interoperabilität mit anderen Syste- ren Anwendungsfälle von Geschäftstransaktionen modellieren

men, dazu gehört außerdem eine geeignete Architektur und werden können.

auf Verteilung spezialisierte Schnittstellen. Dies ist auch einer Neben der Interoperabilität der Schnittstellen bekommt

der größten Kritikpunkte am SOAP-Ansatz, vonseiten der noch ein weiterer Punkt im REST-Architekturstil zentrale Be-

REST-Vertreter. SOAP [3] und die WSDL [4] selbst geben deutung, die Adressierbarkeit der Ressourcen. Grundannahme

keinerlei Standards oder Anregungen vor, wie Schnittstellen hier ist, dass es ein eindeutiges System geben muss, in dem

gestaltet werden sollten, um möglichst interoperabel zu sein. alle Ressourcen direkt identifiziert werden können sollen. Ei-

Allgemein gilt für Schnittstellen, die nicht prozesslokal ge- ne hierarchische Anordnung ist hierbei von Vorteil jedoch

nutzt werden sollen, dass sie möglichst grobgranular zu nicht Kern der Aussage. Ein sehr verbreitetes System zur di-

gestaltet sind. Dazu im Gegensatz sollen prozesslokal ver- rekten Adressierung stellt der URI-Namensraum bereit und

wendete Schnittstellen möglichst feingranular untergliedert mit dem in diesem Zusammenhang oft gebrauchten Hypertext

sein und aus den Prinzipien der objektorientierten Program- Transfer Protocol (HTTP) gibt es außerdem einen sehr ver-

mierung den bestmöglichen Nutzen ziehen.

breiteten Standard, der sich dem REST-Architekturstil

Remote-Interfaces, also nicht prozesslokal genutzte Schnitt- bedient, dazu mehr im folgenden Abschnitt.

stellen, sollten hingegen möglichst dienstorientiert entworfen

C. Das HTTP-REST-Interface

werden. Dies bedeutet, dass sie nur Werte – im Sinne eines

Im HTTP sind acht verschiedene Methoden definiert um Data Transfer Objects – verwenden sollen, nicht jedoch direk-

einfache Abfragen, oder auch komplexere Operationen auf te Objekt-Referenzen, und seiteneffektfrei sind. Damit

einem kompatiblen Server durchzuführen. Unter diesen Ope- ermöglichen sie eine lose Kopplung und sind somit ein we-

rationen gibt es nun vier Spezielle, GET, POST, PUT und sentlicher Faktor für eine hohe Interoperabilität.

DELETE. Diese lassen sich zum einen eins zu eins auf die Ein weitere Punkt ist in diesem Zusammenhang die Perfor-

CRUD-Operationen abbilden (POST=Create, GET=Retrieve, mance von Remote-Interfaces. Diese wird durch

PUT=Update, DELETE=Delete), und zum anderen sind sie grobgranulare Schnittstellen sehr begünstigt, da die Anzahl

der verteilten Methodenaufrufe, gegenüber feingranularen wie in [6] gezeigt vollständig im Sinne der Modellierbarkeit

von Geschäftstransaktionen.

Schnittstellen, deutlich reduziert werden kann.

Damit ist auch verbunden, dass die Aufrufparameter alle In- Damit bilden diese vier HTTP-Methoden eine geeignete

minimale und uniforme Auswahl und lassen sich als Imple- formationen beinhalten müssen, die zum Abarbeiten der

mentierung des REST-Architekturstils verwenden.

Anfrage notwendig sind. Über diese Architektur wird also die

Wie bereits erwähnt, muss für ein uniformes ressourcenge- Komplexität der Schnittstelle reduziert und in eine tiefere

nerisches Interface ein besonderes Augenmerk auf die Schicht verlagert, wodurch man die Einheitlichkeit der nach

außen angebotenen Schnittstelle erreicht. Semantik und die Eigenschaften der Methoden gelegt werden.

Im HTTP sind die Methoden wie folgt spezifiziert.

Dieser Gedanke wird in Verbindung mit dem REST- Architekturstil nun soweit entwickelt, dass man eine Schnitt- GET ist dafür gedacht, die Repräsentation einer Ressource

stelle aus ressourcengenerischen Methoden spezifiziert. abzufragen und soll nach [9] safe und idempotent sein. Safe

Ressourcengenerische Methoden haben eine eindeutige Se- bedeutet in diesem Zusammenhang, dass durch den Aufruf

mantik unabhängig von einer speziellen Ressource, wodurch einer sicheren Methode an einer Ressource, keinerlei weiter-

reichende Wirkung hervorgerufen wird. Ein GET-Aufruf soll Annahmen zu ihrer Wirkungsweise getroffen werden können,

ohne die Ressource kennen zu müssen, auf die sie angewendet also keine weitere Bedeutung haben, als das Abfragen einer

werden. Die Möglichkeit auf Grundlage partiellen Wissens Ressource. Es soll z.B. nicht möglich sein, über einen GET-

Informationen abzuleiten ist sehr positiv im Sinne der Intero- Aufruf Daten zu löschen, zu verändern oder gar einen Vertrag

perabilität, da es dadurch möglich wird Abläufe oder mit jemandem zu schließen. Unter idempotent versteht man,

Zusammenhänge auch für unbekannte Systeme abzuschätzen dass der Seiteneffekt für N > 0 identische Anfragen derselbe

Seminar Advanced Database Technology: RESTful Web Services

3

ist, wie der für eine einzelne Anfrage, abgesehen von Fehlern. (1) Auswählen der anzubietenden Ressourcen aus allen konzeptionellen Entitäten Mit POST wird in lose gekoppelter Art und Weise der Zu- (2) Entwurf der Ressourcen zum schrittweisen Abfragen von stand auf einem Server verändert. Es werden mit dieser weiteren Daten Methode z.B. bestehende Ressource um Kommentare ergänzt, (3) Einen URI für jede Ressource und Vermeidung des RPC-Stils (4) Klassifizieren der Ressourcen nach den auf ihnen ein Beitrag einer Gruppe von Artikeln hinzugefügt, eine Da- ausführbaren Methoden tenbank erweitert oder Daten aus einem Formular übermittelt. (5) Eine Ressourcenabfrage über GET sollten vollständig seitenef- PUT wird verwendet um bestehende Ressourcen an einem fektfrei sein und die Ressource nicht modifizieren (6) Verbindung von Ressourcen über Links in ihren speziellen URI zu ändern, in dem ihr neuer Wert dort abgelegt Repräsentationen herstellen wird oder um an einem bestimmten URI eine neue Ressource (7) Spezifizieren der Abfrageergebnisse mit einer anzulegen. Grundsätzlich ist für das Erstellen einer neuen Schemabeschreibung, für POST und PUT zusätzlich

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 Abb. 3. Acht Prinzipien für RESTful Web Services nach [12] Ressource bekommen wird, wenn diese z.B. in eine Daten- identifiziert, an welche man sich halten sollte um effiziente bank eingefügt wird. PUT soll außerdem idempotent sein. und interoperable Web Services zu erhalten, die auch den se- Mit DELETE wird der Server aufgefordert, eine Ressource mantischen Ansprüchen des REST-Architekturstils gerecht zu löschen. Diese Methode soll ebenfalls idempotent sein. werden. Eine Übersicht über die Prinzipien ist in Abb. 3 zu finden. Im folgenden Abschnitt werden die Fragen durchgear- III. ENTWURF EINES RESTFUL WEB SERVICES beitet und die Prinzipien allgemein erläutert, um sie dann jeweils auf den Bookmark Web Service anzuwenden. A. Ein Bookmark Web Service

Um die abstrakte Beschreibung des REST-Architekturstils C. MyBookmarkWebService

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- Service benötigt werden. Anschließend werden diese konzep- nehmen, welche über Tags also Schlüsselwörter gruppiert tionellen Entitäten dahingehend untersuchen, ob es sinnvoll ist werden können. Zusätzlich soll es die Möglichkeit geben ver- sie nach außen hin anzubieten, wie es Prinzip (1) vorsieht. Für schiedene Gruppen von Bookmarks abzufragen, etwa zu einige Ressourcen ist dies z.B. entweder aus Sicherheitserwä- einem speziellen Schlüsselwort oder von einem bestimmten gungen oder Performanceaspekten heraus nicht sinnvoll. Nutzer. Dabei soll besonders auf den in Abb. 2 dargestellten Der nächste Schritt besteht nun darin, diese Ressourcen Unterschied zwischen dem Entwurf eines ressourcenorientier- nach Prinzip (2) zu optimieren, also so zu strukturieren, detail- ten Systems geachtet werden. Ziel eines RESTful Web lierte Informationen erst auf eine direkte Anfrage zurück Services ist es Ressourcen über URIs verfügbar zu machen gegeben werden. Dies ist sinnvoll um die zu übertragende und nicht Services über eine nachrichtenorientierte Schnitt- Datenmenge zu beschränken und redundante Übertragungen stelle.

zu vermeiden. Diese Untergliederung sollte jedoch nicht zu feingranular werde, sondern es sollte ein gutes Mittel zwi- Nachrichten Ressourcen

operabilitätsüberlegungen aus den vier genannten Operationen Abb. 2. Gegenüberstellung der ressourcenorientierten Sichtweise mit der und wie erwähnt, werden besonders an die GET-Operation nachrichten- bzw. RPC-orientierten Sichtweise auf ein System zusätzlich Anforderungen gestellt, denn diese soll, sicher und B. Vier Fragen und acht Prinzipien idempotent sein.

Für den Entwurf eines RESTful Web Services müssen die Beim Entwerfen des Namensraums scheint es oft bequem folgenden vier Fragen beantwortet werden:

zu sein, in Anlehnung an das unterliegende Objektmodell eine

1) Welche Ressourcen gibt es?

Art RPC-Stil zu verwenden und damit zusätzliche Semantik

2) Welche Repräsentationen sind sinnvoll?

der GET-Operation hinzuzufügen, dies ist jedoch ausdrücklich

3) Welche Methoden werden von den einzelnen Ressourcen zuvermeiden. Ob dies ein scheinbar ungefährliches unterstützt?

http://.../getBookmark?id=4 oder ein offensichtlich

4) Welche Status-Codes bzw. Fehler können zurückgegeben problematischeres http://.../deleteBookmark?id=4 werden?

ist sei dabei erstmal nicht relevant. Als Regel gilt, zur Identifi- Mit dem Beantworten dieser Fragen erhält man die zierung von Ressourcen werden Nomen verwendet und keine notwenigen Informationen für eine anschließende Implemen- Verben. Dass die zusätzliche Semantik große Probleme birgt, tierung. Zusätzlich wurden in [12] acht Prinzipien

Seminar Advanced Database Technology: RESTful Web Services

4

sowie der Liste der bestellten Produkte zusammensetzt. In der P P TABELLE I Repräsentation dieser Bestellung sollten keine Produktbe- URI-NAMENSRAUM

repräsentiert um von allen Bookmarks der Benutzer die 20 worte Neusten auswählen zu können.

{user}/profile Nutzerprofil Profil von {user}

2) Welche Repräsentationen sind sinnvoll? all/bookmarks/ Bookmark- Die 20 neusten Book-

vices geschickt so zu verbinden, dass es möglich wird, ohne zeigt ein einfaches Beispiel. Unteranderem verlässt sich Zusatzinformationen den Dienst schrittweise in Anspruch Google darauf, dass GET eine sichere Operation ist und parst nehmen zu können. Dies wird realisiert, in dem in den Reprä- so das Web. Sollte Google nun auf einen potenziell nicht ab- sentationen der Ressourcen Links auf andere Ressourcen mit gesicherten Service treffen, der diese erweiterte GET- einem semantischem Zusammenhang eingebettet werden, wie Semantik implementiert, ist es durch aus denkbar, wenn auch es Prinzip (6) vorsieht. Dadurch wird explizit der Zusammen- hoffentlich nicht realistisch, dass alle mühsam gesammelten hang zwischen den Ressourcen ausgedrückt und auch eine Bookmarks mit einmal gelöscht werden. Daher sollte jegliche automatisierte auf partiellem Wissen über den Services ge- nicht [9] entsprechende Semantik vermieden werden. stützte Nutzung begünstigt.

Weiterhin gilt, dass Ressourcen selbst eindeutig ohne eine Für die vier hier gewählten Ressourcenarten gilt es nun, un- Query in dem URI identifiziert werden können sollen, da Que- ter Beachtung von Prinzip (6), geeignete Repräsentationen zu ry in [15] als die Zeichenkette definiert ist, welche hinter wählen. In [13] wird ein Format für Bookmarks beschrieben, einem ?-Zeichen angegeben ist und Informationen beinhaltet, welches die nötigen Eigenschaften für den angedachten Ser- welche von der Ressource selbst interpretiert werden sollen vice mitbringt und somit als Grundlage dienen wird. Das und somit zur Ressourcenidentifikation nur die URI-Teile vor Format wird hier selbst nicht noch einmal von Grund auf er- dem ?-Zeichen infrage kommen. Queries sollten immer dann läutert, sondern es wird nur auf die für den Service nötigen verwendet werden, wenn die daraufhin erzeugten Ergebnisse Erweiterungen eingegangen. Genauere Informationen sind in nicht selbst als Ressource gewertet werden sollen. der Spezifikation unter [13] zu finden oder in den Beispielen Von Anfang an angewendet auf dieses Beispiel ergeben von [10], auf den dieser Beispiel-Service basiert. sich erst einmal die Ressourcen. Diese sind einzelne Book-

marks, Sammlungen von Bookmarks, einzelne dem Standard eigene Erweiterungen zu, welche über das Schlüsselworte, Listen von Schlüsselworten, sowie die Nut- owner Attribut unterschieden werden können. Es wird über zerprofile als einzelne Ressourcen, welche z.B. Verweise auf dieses Attribut die Art der im Tag hinterlegten Informationen die Sammlung von Bookmarks und verwendeten Schlüssel- angegeben. Die Metadaten mit der Identifikation xbel- worte des einzelnen Users enthalten können. Bis auf die ext/baseuri sind eingefügt worden, um dem Prinzip (6) einzelnen Schlüsselworte als eigenständige Ressource müssen Rechnung zu tragen, denn hier wird der URI des Bookmarks in diesem Fall alle Entitäten nach außen zur Verfügung ge- auf dem Server angegeben, über welche später z.B. Update- 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 Abb. 4. Beispiel für ein Bookmark im XBEL-Format

Seminar Advanced Database Technology: RESTful Web Services

5

gebrauch gemacht werden, um dem Interoperabilitätsgedan- oder Löschoperationen möglich sind. Da die Bookmarks in ken Rechnung zu tragen, da besonders Fehler oft durch diesem Format auch in der Repräsentation von Bookmark- unterschiedliche Definitionen die Interoperabilität beeinträch- sammlungen Verwendung finden, ist es somit auch aus einer tigen, auch wenn die Schnittstelle an sich sauber Sammlung heraus möglich einzelne Bookmarks später zu ad- implementiert wurde. Wenn der Server die Anfrage nicht in- ressieren. Die zweite Erweiterung xbel-ext/tags wird terpretieren kann, ist z.B. der Status-Code 400 zurückzugeben verwendet um die dem Bookmark zugeordneten Schlüssel- oder falls Fehler bei der Abarbeitung auf dem Server auftreten wörter anzugeben.

der Status-Code 500.

Die Repräsentation einer Bookmarksammlung wird im sel- Aber nicht nur Fehler sondern auch Erfolgsmeldungen soll- ben XBEL-Format angegeben, nur mit mehreren ten standardkonform verwendet werden. So sollte auf das -Elementen unter dem -Wurzelelement. Hinzufügen eines Bookmarks zu einer Sammlung z.B. mit Für die Darstellung einer Liste von Schlüsselworten wird dem Status-Code 201 reagiert werden und entweder der URI wie im Beispiel, eine einfache Sequenz von -Tags ver- zurückgegeben werden, unter dem das neue Bookmark zu wendet, welche zusätzlich in einem -Wurzelelement finden ist, oder die komplette Repräsentation des Bookmarks. eingebettet ist.

Auf die Festlegung eines speziellen Formats für das Nut- disierten Status-Codes ist in [9] Abschnitt 10 zu finden. 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- nes Services. Prinzip (7) und (8) gehen daher explizit auf sammlungen erinnert.

diesen Umstand ein. Die Repräsentationen der Ressourcen

3) Welche Methoden werden von den einzelnen sollten immer in einem geeigneten Format spezifiziert werden, Ressourcen unterstützt?

um einem Konsumenten die vollständige Nutzung zu ermögli- Um diese Frage zu beantworten, macht sich eine tabellari- chen. Für XML-Daten bieten sich hier die gängigen sche Auflistung gut. Als Erstes muss überlegt werden, welche Spezifikationssprachen an, aber auch bei Binärformaten sollte Methoden auf die einzelnen Ressourcenarten anwendbar sein stets eine Spezifikation zur Verfügung gestellt werden, um die sollen, um sie anschließend geordnet nach den möglichen Me- Nutzung zu vereinfachen.

thoden in die Tabelle eintragen zu können. Für die Beschreibung der Servicestruktur an sich, ist es Dieses Vorgehen lässt sich aus dem Prinzip (4) ableiten und ebenso sinnvoll eine im besten Fall auch maschinenlesbare erhöht die Übersichtlichkeit beim Entwurf. Vollständig ausge- füllt beinhaltet die Tabelle somit eine komplette Beschreibung TABELLE II

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 und 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 werden verschiedene Status-Codes für die wich- tigsten Situationen definiert und von diesen sollte möglichst

Seminar Advanced Database Technology: RESTful Web Services

6

auf der gleichen Höhe und zusätzlich vermeidet man Abhän- Spezifikation zu erstellen. Dies kann z.B. über die WSDL

gigkeiten zu Schnittstellen, die eventuell anfragerbezogen sein geschehen, welche voraussichtlich in der kommenden Version

könnten.

2.0 die Beschreibungsmöglichkeiten für RESTful Web Ser-

vices weiter verbessert oder – dann aber nicht unbedingt C. Direkt Adressierung im URI-Namensraum

maschinenlesbar – mittels eines für den Menschen aufbereite- Wie bereits angerissen ermöglicht die Verwendung des ten Dokuments, z.B. als simple HTML-Seite.

URI-Namensraums eine direkte Adressierung aller Ressour- Wie auf einer gängigen Internetseite sollte es auch für diese cen. Wenn hier zusätzlich noch eine Beschränkung auf Services üblich sein, eine Eintrittseite bzw. Ressource zu er- Identifikatoren unter dem HTTP eingeführt wird, ermöglicht stellen, welche die für den Service wesentlichen Ressourcen dies einen uniformen Umgang mit diesen Ressourcen über ein referenziert, so wird es möglich über einen einzigen URI den einziges Protokoll und damit prinzipiell weitreichender Inter- gesamten Service verfügbar zu machen.

operabilität.

Dazu im Gegensatz steht die Verwendung von SOAP als IV. WEITERE EINSATZMÖGLICHKEITEN UND VORTEILE Grundlage für ein Applikationsprotokoll. Über diesen Ansatz

sind die Ressourcen des Services nicht mehr direkt über einen A. Transaktionen in ressourcenorientierten Web Services

eindeutigen URI zugänglich, sondern es muss der Weg über Für die Realisierung von komplexen Geschäftsabläufen ist eine SOAP-Ressource genommen werden, welche die eigent- es unerlässlich die ACID-Eigenschaften (Atomicity, Consis- lichen Ressourcen versteckt. Durch diese Maßnahme werden tency, Isolation, Durability) garantieren zu können. Nun ist diese Ressourcen in einen eigenen Namensraum verlagert und die Frage, ob RESTful Web Services konzeptionell so etwas somit eine direkte Adressierung deutlich erschwert, wenn wie einen Transaktionsmanager zulassen, wo eine der Haupt- nicht teilweise unmöglich gemacht, womit die Interoperabili- grundsätze ja die Zustandslosigkeit – im Sinne der tät dieser Dienste, im Vergleich zu Diensten die einen Vermeidung von anfrageübergreifenden Sessioninformationen gemeinsamen, den allgemeinen URI-Namensraum nutzen, – des Servers ist. Eine Möglichkeit der Modellierung wäre, eingeschränkt wird und dass obwohl die meisten SOAP-Web die Ressourcen so zu gestallten, dass es nicht nötig wird Service sich selbst dieses Vorteils bedienen und direkt über Transaktionen über mehrere Anfragen hinweg zu unterstützen. einen URI ansprechbar sind.

Falls dies nicht möglich ist, wäre der folgende Ansatz eine Ein weiterer Punkt für diese Form der Adressierung von mögliche Lösung.

Ressourcen ist das Discovery Problem. Auf HTTP-REST auf- Denkbar wäre eine Ressource im Sinne eines Transakti- bauende Web Services sind ohne weiteres über allgemeine onsmanagers, welcher Anträge auf Transaktionen verwaltet. oder spezialisierte Web-Suchmaschinen auffindbar und erfor- Mittels einer Anfrage, die dem Transaktionsmanager einen dern somit keine zusätzliche Technologie.

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 Bei der Verwendung von HTTP als eine REST Implemen- den ACID-Eigenschaften genügen sollen, können mit einer tierung, ergeben sich einige weitere Vorteile, so gibt es für die Referenz auf diese Transaktionsressource auf dem Server großen Problemfelder der Nutzerauthentifikation und Sicher- durchgeführt werden, bzw. ihre Repräsentationen auf dem heit bereits Lösungen, die erprobt sind. Unter anderem Server abgelegt werden. Um die Transaktion abzuschließen, verschiedene Verfahren zur Authentifikation z.B. über Zertifi- wird ein weiterer Antrag an die Transaktionsmanager- kate oder auch Verschlüsselung z.B. durch HTTP over TLS. Ressource gestellt, über den das Commit der Transaktion an- Des Weiteren ist es ohne weiteres möglich, auch nicht- gestoßen wird. Abschließend kann die Transaktion beendet XML Daten effizient zu übertragen, was bei SOAP, da es und die Transaktionsressource freigegeben werden.

komplett XML-basiert ist, problematisch bzw. ineffizient ist,

wenn man nicht z.B. SOAP with Attachments nutzen kann, B. Asynchrone Web Services

weil dies nicht von allen Clients unterstützt wird.

Für einige Arten von Services ist es wünschenswert eine Mit der Verwendung von HTTP in einem aus semantischer zeitliche Entkopplung, zwischen dem Stellen der Anfrage und Sicht richtigen Sinne wird außerdem das Filtern und Loggen dem Erhalten einer Antwort darauf, realisieren zu können. Da der Anfragen möglich, wie es für Webseiten seit Langem üb- HTTP selbst dafür keine Mechanismen vorsieht, bleibt hier lich ist. Tools für Monitoring-Aufgaben lassen sich ebenso nur die Möglichkeit, den Serviceanbieter entweder in be- weiter verwenden, ohne sie speziell anpassen zu müssen. stimmten zeitlichen Abständen oder nach Vereinbarung auf

Abarbeitung der Anfrage anzusprechen. Dies hat auch aus E. REST vs. SOAP

architektureller Sicht einige Vorteile. Durch dieses Vorgehen benötigt der Server selbst keinerlei Informationen über den der Tatsache, dass ein einziges universelles Protokoll mit einer Anfragesteller und muss auch keine Information oder Mecha- eindeutig spezifizierten Schnittstelle genutzt wird.

nismen verwalten, um sicherzustellen, dass die Antwort auch Dahingegen ist SOAP deutlich im Nachteil, wenn es um In- beim Anfragenden ankommt. Damit bleibt die Komplexität teroperabilität geht. Der Hauptgrund dafür ist, dass SOAP im des Servers auch für asynchrone Ausführung von Anfragen Eigentlichen nur ein Framework für applikationsspezifische

Seminar Advanced Database Technology: RESTful Web Services

7

meisten Probleme bereits Lösungen gibt. Seien dies nun Protokolle ist. Mit SOAP als Grundlage werden somit ver- Logging, Monitoring, Authentifizierung oder das Filtern von schiedene eigene Protokolle spezifiziert, die für jeden unerwünschten Operationen an einer Firewall.

Anbieter unterschiedlich sind. Dies schließt sämtliche Vorteile Das Problem, des Integrationsaufwands, löst dieser Ansatz aus, die darauf basieren, dass es ein oder zumindest wenige jedoch auch nicht vollständig. Dieser ist weiterhin der Ord- gut verstandene, eindeutige Protokolle gibt. Darunter fallen nung O(n 2 ), wenn auch tendenziell geringer als bei der nicht nur die Möglichkeiten, die Filter haben, welche auf Grundlage von HTTP arbeiten, sondern vor allem auch die Verwendung von nicht uniformen Schnittstellen.

integrativen Vorteile, da nicht nur ein Protokoll mit verschie- LITERATUR denen Ressourcen, sondern viele Protokolle mit potenziell

vielen Ressourcen unterstützt werden müssen.

[1] Roy Thomas Fielding, „Architectural Styles and the Design of Network- Ein weiteres in SOAP noch nicht gelöstes Problem ist die nia, Irvine, 2000, S. 76ff.

Integration der sich stets erhöhende Zahl von Standards, wel- [2] M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, R. Stafford, Pat- che die Kompatibilität der SOAP-Implementierungen terns of Enterprise Application Architecture. Addison Wesley, 2002. untereinander behindert. Unteranderem gilt dies für den kom- [3] M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. F. Nielsen, SOAP Version 1.2, 2003, http://www.w3.org/TR/soap12/ menden WS-Addressing Standard, welcher es ermöglicht [4] E. Christensen, F. Curbera, G. Meredith, S. Weerawarana, Web Services Service-Endpunkte und Nachrichten zu adressieren. Genau Description Language (WSDL) 1.1, 2001, http://www.w3.org/TR/wsdl dieses Problem resultiert aus der Verlagerung der Ressourcen [5] Carlos E. Perez (2005, März). Why REST is Better - Part 2 - Contract Based Protocols,

in einen neuen Namensraum und wird von HTTP-REST deut- lich geschickter gelöst.

[6] Carlos E. Perez (2004, Juni). The RESTfulness of Speech Acts, F. Integrationsaufwand bei Verwendung uniformer Schnitt- acts/view stellen [7] Carlos E. Perez (2005, März). Artikelreihe Why REST is Better, http://www.manageability.org/blog/stuff/rest-explained-in-code/view Allgemein ist der Aufwand zur Integration von n verschie- [8] Eckhardt Holz, Script zur Vorlesung Softwarearchitektur, WS2005/06, denen Knoten in einem Netz der Ordnung O(n 2 ). Auch in Hasso-Plattner-Institut, Universität Potsdam einem auf einer REST-Implementierung aufsetzenden Netz ist [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- dies a priori nicht anders als in Netz bei denen jeder Knoten net Engineering Task Force, Juni 1999.

über eine eigene Schnittstelle angesprochen wird, da die An- [10] Joe Gregorio (2005, März). Show Me the Code zahl der vorstellbaren Ressourcen für ein spezielles Problem http://www.xml.com/pub/a/2005/03/02/restful.html [11] Paul Prescod (2002, September). Common REST Mistakes weiterhin nicht eingeschränkt ist. Dies könnte nur durch Stan- http://www.prescod.net/rest/mistakes/ dardisierung in diesem Problemfeld erreicht werden. [12] Roger L. Costello (2003, Januar). Building Web Services the REST Way Allerdings gibt es Hypothesen, die besagen, dass der Ge- http://www.xfront.com/REST-Web-Services.html samtaufwand deutlich geringer ist als bei Systemen, die [13] Fred L. Drake, Jr. The XML Bookmark Exchange Language, CNRI, Reston, USA, Oktober 1998. http://pyxml.sourceforge.net/topics/xbel/ jeweils unterschiedliche Schnittstellen nutzen, was offensicht- [14] Zitatsammlung verschiedener Autoren (2004, Mai). InterfaceGenericity lich nachvollziehbar ist, und sich dieser Gesamtaufwand http://rest.blueoxen.net/cgi-bin/wiki.pl?InterfaceGenericity deutlich in Richtung Ordnung O(n) bewegt und somit wesent- [15] T. Berners-Lee, R. Fielding, L. Masinter. RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. Internet Engineering Task Force, Au- lich effizienter ist als gängige Integrationsstrategien auf SOAP gust 1998.

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