Die ressourcenorientierte Architektur - beim O'Reilly Verlag

Frischer Wind für 

Web Services durch REST 

Deutsche 

Ausgabe 

Web Services 

mit 

REST 

O’Reilly 

Leonard Richardson & Sam Ruby 

Deutsche Übersetzung von 

Thomas Demmig & Sebastian Tussing

Web Services mit REST 

Leonard Richardson und Sam Ruby 

Deutsche Übersetzung von 

Thomas Demmig und Sebastian Tussing 

Beijing · Cambridge · Farnham · Köln · Paris · Sebastopol · Taipei · Tokyo

Die Informationen in diesem Buch wurden mit größter Sorgfalt erarbeitet. Dennoch können 

Fehler nicht vollständig ausgeschlossen werden. Verlag, Autoren und Übersetzer übernehmen 

keine juristische Verantwortung oder irgendeine Haftung für eventuell verbliebene Fehler und 

deren Folgen. 

Alle Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt und sind 

möglicherweise eingetragene Warenzeichen. Der Verlag richtet sich im Wesentlichen nach den 

Schreibweisen der Hersteller. Das Werk einschließlich aller seiner Teile ist urheberrechtlich 

geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, 

Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. 

Kommentare und Fragen können Sie gerne an uns richten: 

O’Reilly Verlag 

Balthasarstr. 81 

50670 Köln 

Tel.: 0221/9731600 

Fax: 0221/9731608 

E-Mail: kommentar@oreilly.de 

Copyright der deutschen Ausgabe: 

© 2007 by O’Reilly Verlag GmbH & Co. KG 

1. Auflage 2007 

Die Originalausgabe erschien 2007 unter dem Titel 

RESTful Web Services bei O’Reilly Media, Inc. 

Die Darstellung eines Fuchskusu im Zusammenhang 

mit dem Thema Web Services mit REST ist ein 

Warenzeichen von O’Reilly Media, Inc. 

Bibliografische Information Der Deutschen Bibliothek 

Die Deutsche Bibliothek verzeichnet diese Publikation in der 

Deutschen Nationalbibliografie; detaillierte bibliografische Daten 

sind im Internet über http://dnb.ddb.de abrufbar. 

Übersetzung und deutsche Bearbeitung: Thomas Demmig, Sebastian Tussing, Mannheim 

Lektorat: Volker Bombien, Köln 

Fachliche Begutachtung: Dr. Claudia Nölker, Bielefeld 

Korrektorat: Eike Nitz, Köln 

Satz: DREI-SATZ, Husby 

Umschlaggestaltung: Michael Oreal, Köln 

Produktion: Andrea Miß, Karin Driesen, Köln 

Belichtung, Druck und buchbinderische Verarbeitung: 

Druckerei Kösel, Krugzell; www.koeselbuch.de 

ISBN 978-3-89721-727-0 

Dieses Buch ist auf 100% chlorfrei gebleichtem Papier gedruckt.

First 

Inhalt 

Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

IX 

XI 

Max. 

Linie 

1 Das programmierbare Web und seine Bewohner . . . . . . . . . . . . . . . . . . . . . . . 1 

Lebewesen im programmierbaren Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

HTTP: Dokumente in Umschlägen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

Methodeninformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

Fokusinformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

Die konkurrierenden Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Technologien im programmierbaren Web . . . . . . . . . . . . . . . . . . . . . . . . . 20 

Weitere Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

2 Clients für Web Services schreiben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

Web Services sind Web-Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

del.icio.us: Die Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

Einen Request stellen: HTTP-Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . 31 

Verarbeiten der Response: XML-Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

JSON-Parser: Umgang mit serialisierten Daten . . . . . . . . . . . . . . . . . . . . . 48 

Clients ganz einfach – mit WADL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 

3 Was macht REST-konforme Services anders? . . . . . . . . . . . . . . . . . . . . . . . . . . 55 

Einführung in den Simple Storage Service . . . . . . . . . . . . . . . . . . . . . . . . . 55 

Objektorientiertes Design von S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 

HTTP-Responsecodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

Ein S3-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

Signierte Requests und Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . 72 

Verwenden der S3-Client-Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

Max. 

Linie 

This is the Title of the Book, eMatter Edition 

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved. 

| V

Transparente Clients durch ActiveResource . . . . . . . . . . . . . . . . . . . . . . . 80 

Abschlusswort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 

Links 

Max. 

Linie 

4 Die ressourcenorientierte Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 

Ressourcenorientiert: Warum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 

Was ist eine Ressource? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 

URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 

Adressierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 

Zustandslosigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 

Repräsentationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 

Verweise und Verbindungshaftigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 

Die einheitliche Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 

Das war’s! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 

5 Entwurf von nur lesbaren ressourcenorientierten Services . . . . . . . . . . . . . . . . 121 

Ressourcendesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 

Anforderungen in nur lesbare Ressourcen umwandeln . . . . . . . . . . . . . . . 124 

Welche Daten sind notwendig? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 

Unterteilen der Daten in Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 

Benennen der Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 

Entwerfen Sie Ihre Repräsentationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 

Verbinden der Ressourcen miteinander . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 

Die HTTP-Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 

6 Entwurf von les- und schreibbaren ressourcenorientierten Services . . . . . . . . . 161 

Benutzerkonten als Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

Eigene Orte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 

Ein Blick zurück auf den Kartenservice . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 

7 Eine Service-Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

Ein Social Bookmarking-Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 

Welche Daten werden benötigt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 


Vom Client kommende Repräsentation(en) entwerfen . . . . . . . . . . . . . . . 207 

Repräsentation(en) zum Senden an den Client entwerfen . . . . . . . . . . . . . 210 

Ressourcen miteinander verbinden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 

Was soll passieren? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 

Was kann schiefgehen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 

Controller-Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 

Model-Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 

Was muss der Client wissen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 

Max. 

Linie 

VI | Inhalt 


Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Rechts 

8 Best Practices: REST und ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 

Ressourcenorientierte Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 

Der allgemeine ROA-Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 

Addressierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 

Zustand und Zustandslosigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

Connectedness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 

Die einheitliche Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 

Das ist wirklich wichtig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 


URI-Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 

Ausgehende Repräsentationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265 

Eingehende Repräsentationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 

Versionierung des Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 

Permanente URIs vs. lesbare URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268 

Standardeigenschaften von HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270 

PUT und DELETE vortäuschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 

Ärger mit Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 

Warum einem HTTP-Client trauen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288 

Max. 

Linie 

9 Die Bausteine eines Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 

Repräsentationsformate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 

Zusammengestellte Kontrollflüsse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 

Hypermedia-Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 

10 Die ressourcenorientierte Architektur vs. dicke Web Services . . . . . . . . . . . . . . 343 

Welche Probleme versuchen dicke Web Services zu lösen? . . . . . . . . . . . . 344 

SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 

WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 

UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 

Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 

Reliable Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 

Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 

BPEL, ESB und SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 

11 Ajax-Anwendungen als REST-Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 

Von AJAX zu Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 

Die Ajax-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 

Ein del.icio.us-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 

Die Vorteile von Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 

Die Nachteile von Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 

REST geht besser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371 

Max. 

Linie 



Inhalt | VII

Durchführung des Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 

Verarbeitung der Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 

JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 

Behalten Sie nicht die Vorteile von REST für sich . . . . . . . . . . . . . . . . . . . 376 

Cross-Browser-Probleme und Ajax- Bibliotheken . . . . . . . . . . . . . . . . . . . 378 

Das Sicherheitsmodell des Browsers untergraben . . . . . . . . . . . . . . . . . . . 382 

Links 

12 Frameworks für REST-konforme Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 

Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 

Restlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396 

Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 

A Einige Ressourcen für REST und einige REST-konforme Ressourcen . . . . . . . . . 421 

Standards und Leitfäden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 

Services, die Sie verwenden können . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 

B Die wichtigsten 42 HTTP-Responsecodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 

Drei bis sieben Statuscodes: Das Minimum . . . . . . . . . . . . . . . . . . . . . . . . 430 

1xx: Meta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 

2xx: Erfolgreich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 

3xx: Weiterleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 

4xx: Fehler auf Clientseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 

5xx: Fehler auf Serverseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447 

C Die HTTP-Header-Hitliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 

Standard-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452 

Header außerhalb des Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 

Max. 

Linie 

Max. 

Linie 

VIII | Inhalt 


Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

First 

Kapitel 4 

KAPITEL 4 

Hier Mini IVZ eingeben! 

Die ressourcenorientierte Architektur 

Erstellen auf den 

Arbeitsseiten 

(siehe Muster) 

Max. 

Linie 

Abstand untere Tabellenlinie zu Textanfang 1,8 cm 

-> also: manuell auf den Arbeitsseiten ziehen!!! 

Ich habe Ihnen zwar die Möglichkeiten von REST gezeigt, habe dabei aber nicht systematisch 

erklärt, wie sie strukturiert sind oder wie man sie auch verfügbar macht. In 

diesem Kapitel beschreibe ich eine konkrete REST-konforme Architektur: die ressourcenorientierte 

Architektur (ROA). ROA ist ein Weg, um ein Problem in einen 

REST-konformen Web Service umzuwandeln: eine Kombination aus URIs, HTTP 

und XML, die so wie der Rest des Webs funktioniert und die Programmierer gerne 

nutzen werden. 

In Kapitel 1 habe ich REST-konforme Web Services anhand der Beantwortung von 

zwei Fragen klassifiziert. Diese Antworten entsprechen zwei der vier definierenden 

Features von REST: 

• Die Fokusinformation (»Warum sollte der Server diese Daten senden und nicht 

jene?«) befindet sich in dem URI. Das ist das Prinzip der Adressierbarkeit. 

• Die Methoden-Information (»Warum sollte der Server die Daten schicken und 

nicht löschen?«) befindet sich in der HTTP-Methode. Es gibt nur ein paar 

HTTP-Methoden und man weiß schon vorher, was sie tun. Das ist das Prinzip 

der einheitlichen Schnittstelle. 

In diesem Kapitel stelle ich die Kernbestandteile der ressourcenorientierten 

Architektur vor: Ressourcen (natürlich), ihre Namen, ihre Repräsentationen und die 

Verweise zwischen ihnen. Ich erläutere die Eigenschaften der ROA: Adressierbarkeit, 

Zustandslosigkeit, Verbindungshaftigkeit und die einheitliche Schnittstelle. 

Ich zeige, wie die Web-Technologien (HTTP, URIs und XML) diese Bestandteile 

implementieren, um die Eigenschaften möglich zu machen. 

In den vorigen Kapiteln habe ich Konzepte präsentiert, indem ich bestehende Web 

Services vorgestellt habe, wie zum Beispiel S3. Ich will das in diesem Kapitel fortführen, 

möchte aber Konzepte zusätzlich deutlich machen, indem ich auf bestehende 

Web-Sites verweise. Ich habe Sie hoffentlich schon davon überzeugt, dass 

Web-Sites auch Web Services sind und dass viele Web-Anwendungen (wie zum 

Beispiel Suchmaschinen) REST-konforme Web Services darstellen. Wenn ich über 

Max. 

Linie 

Dies ist ein Auszug aus dem Buch „Web Services mit REST“, ISBN 978-3-89721-727-0 

This is http://www.oreilly.de/catalog/restfulwsger/ 

the Title of the Book, eMatter Edition 

Dieser Auszug unterliegt dem Urheberrecht. © O'Reilly Verlag 2008 


| 89

Max. 

Linie 

abstrakte Konzepte wie Adressierbarkeit spreche, ist es hilfreich, Ihnen reale URIs zu 

zeigen, die Sie in Ihren Web-Browser eintippen können, um die Konzepte auch im 

wahren Leben zu sehen. 

Ressourcenorientiert: Warum? 

Warum komme ich hier mit einem neuen Begriff an, ressourcenorientierte Architektur? 

Warum schreibe ich nicht einfach REST? Nun, auf dem Buch steht vorne REST 

drauf und ich sage auch, dass alles in der ressourcenorientierten Architektur RESTkonform 

ist. Aber REST ist keine Architektur, sondern eine Zusammenstellung von 

Designkriterien. Sie können sagen, dass eine Architektur diese Kriterien besser 

erfüllt als eine andere, aber es gibt nicht die eine »REST-Architektur«. 

Bisher neigten die Leute eher dazu, jedes Mal beim Entwerfen ihrer Services eine 

neue Architektur nur für diesen einen Fall zu entwerfen – und zwar entsprechend 

ihrem eigenen Verständnis von REST. Das offensichtlichste Ergebnis davon ist die 

große Anzahl von REST-RPC-Hybrid-Web Services, von denen ihre Erbauer 

behaupten, sie seien REST-konform. Ich versuche, das zu beenden, indem ich eine 

Reihe konkreter Regeln für das Erstellen von Web Services vorstelle, die wirklich 

REST-konform sind. In den nächsten beiden Kapiteln werde ich sogar einfache 

Vorgehensweisen zeigen, denen Sie folgen können, um Anforderungen in Ressourcen 

umzuwandeln. Wenn Sie meine Regeln nicht mögen, bekommen Sie zumindest 

eine Idee davon, was Sie ändern können, ohne dabei weniger REST-konform zu werden. 

Als Sammlung von Designkriterien ist REST sehr allgemein. Insbesondere ist es nicht 

an das Web gebunden. Nichts in REST hängt von den Mechanismen von HTTP oder 

der Struktur von URIs ab. Aber ich spreche hier über Web Services, daher verbinde 

ich die ressourcenorientierte Architektur explizit mit den Web-Technologien. Ich 

möchte darüber reden, wie man REST mit HTTP und URIs umsetzen kann – in spezifischen 

Programmiersprachen. Wenn die Zukuft REST-konforme Architekturen 

schafft, die nicht auf dem Web aufsetzen, werden deren Best Practices wohl ähnlich 

wie ROA aussehen, die Details sich aber unterscheiden. Wir werden das noch näher 

betrachten, wenn wir dorthin gelangen. 

Die klassische Definition von REST enthält eine Menge Freiräume, die von den 

Anwendern mit Eigenkreationen gefüllt wurden. Ich gehe mit Absicht weiter als Roy 

Fielding in seiner Dissertation oder das W3C in seinen Standards: Ich möchte einige 

der »offenen« Bereiche klarer gestalten, so dass die Eigenentwürfe sich zu wohldefinierten 

Best Practices entwickeln. Selbst wenn REST eine Architektur wäre, 

fände ich es nicht fair, meine Architektur genauso zu benennen. Ich würde meine 

empirischen Beobachtungen und Vorschläge mit den allgemeiner gehaltenen Gedanken 

derer verbinden, die das Web aufgebaut haben. 

Links 

Max. 

Linie 

90 | Kapitel 4: Die ressourcenorientierte Architektur 




http://www.oreilly.de/catalog/restfulwsger/ 

Dieser Auszug unterliegt dem Urheberrecht. © O'Reilly Verlag 2008

Rechts 

Mein letzter Grund für einen neuen Begriff ist, dass »REST« in Glaubenskriegen von 

Nerds verwendet wird. Seine Nutzung geschieht häufig im Zusammenhang mit der 

Meinung, dass es nur eine wirklich REST-konforme Architektur gibt – die, die der 

Sprecher bevorzugt. Leute, die andere REST-konforme Architekturen eher mögen, 

widersprechen. Die REST-Gemeinschaft ist zersplittert, obwohl es eine gemeinsame 

Basis in Bezug auf Dinge wie den Wert von URIs und HTTP gibt. 

Idealerweise sollte es keine Glaubenskriege geben, aber ich habe genug gesehen, um 

zu wissen, dass dieser Wunsch nicht für ihr Ende sorgen wird. Daher gebe ich meiner 

Philosophie, wie REST-konforme Anwendungen entworfen werden sollten, einen 

anderen Namen. Wenn diese Ideen – was zwangsläufig geschehen wird – als Munition 

in solchen Kriegen genutzt werden, können Leute, die mit mir nicht übereinstimmen, 

Elemente der ressourcenorientierten Architektur von anderen RESTkonformen 

Architekturen und von REST im Allgemeinen trennen. Klarheit ist der 

erste Schritt zum Verständnis. 

Die Begriffe »ressourcenorientiert« und »ressourcenorientierte Architektur« wurden 

genutzt, um REST-konforme Architekturen im Allgemeinen zu beschreiben. 1 Ich 

denke nicht, dass »ressourcenorientierte Architektur« ein komplett neuer Begriff ist, 

aber ich glaube, dass meine Verwendung gut zu früheren Nutzungen passt und es 

besser ist, diesen Begriff zu nutzen, als für REST als Ganzes zu sprechen. 

Was ist eine Ressource? 

Eine Ressource ist alles, was wichtig genug ist, um als eigenständiges Etwas referenziert 

zu werden. Wenn Ihre Benutzer »einen Hypertext-Verweis dafür erstellen, 

Annahmen darüber erstellen oder widerrufen, eine Darstellung davon holen oder 

speichern, alles oder Teile davon per Referenz in andere Darstellungen übernehmen, 

es kommentieren oder andere Operationen darauf ausführen wollen«, sollten Sie es 

zu einer Ressource machen. 2 

Normalerweise ist eine Ressource etwas, das auf einem Computer gespeichert und 

als Bit-Stream dargestellt werden kann: ein Dokument, eine Zeile in einer Datenbank 

oder das Ergebnis eines Algorithmus. Eine Ressource kann ein physikalisches Objekt 

Max. 

Linie 

1 Die älteste Erwähnung von »ressourcenorientiert«, die ich gefunden habe, ist in einem Artikel aus der 

IBM developerWorks von 2004 von James Snell: »Resource-oriented vs. activity-oriented Web services« 

(http://www-128.ibm.com/developerworks/xml/library/ws-restvsoap/). Alex Bunardzic hat »ressourcenorientierte 

Architektur« im August 2006 genutzt, bevor dieses Buch angekündigt worden war: http:// 

jooto.com/blog/index.php/2006/08/08/replacing-service-oriented-architecture-with-resource-orientedarchitecture/. 

Ich stimme nicht mit allem in diesen Artikeln überein, aber ich gebe zu, dass sie die Terminologie 

schon zuvor genutzt haben. 

2 »The Architecture of the World Wide Web« (http://www.w3.org/TR/2004/REC-webarch-20041215/ 

#p39), worin viel Zitierwürdiges zu finden ist, so zum Beispiel: »Softwareentwickler sollten davon ausgehen, 

dass eine Nutzung der gleichen URIs in mehreren Anwendungen nützlich sein wird, auch wenn 

das nicht gleich offensichtlich ist.« Das könnte der Schlachtruf für die ROA sein. 

Max. 

Linie 

Was ist eine Ressource? 


| 91 





sein wie ein Apfel oder ein abstraktes Konzept wie Mut, allerdings ist (wie wir später 

sehen werden) die Darstellung solcher Ressourcen meist eher enttäuschend. 

Hier ein paar mögliche Ressourcen: 

• Version 1.0.3 des Software-Release 

• die letzte Version des Software-Release 

• der erste Weblog-Eintrag am 24. Oktober 2006 

• eine Straßenkarte für Little Rock, Arkansas 

• Informationen über Quallen 

• ein Verzeichnis mit Ressourcen über Quallen 

• die nächstgrößere Primzahl nach 1024 

• die nächsten fünf Primzahlen nach 1024 

• die Verkaufszahlen für das 4. Quartal 2004 

• die Beziehung zwischen Alice und Bob 

• eine Liste der offenen Fehler in der Fehlerdatenbank 

Links 

URIs 

Was macht aus einer Ressource eine Ressource? Sie muss mindestens einen URI 

haben. Der URI ist der Name und die Adresse einer Ressource. Wenn eine Information 

keinen URI hat, ist sie keine Ressource und befindet sich auch nicht wirklich im 

Web, höchstens als Datenhäppchen, das andere Ressourcen beschreibt. 

Erinnern Sie sich an die Beispielsession in der Einführung, bei der ich ein wenig Spaß 

mit HTTP 0.9 hatte? Lassen Sie uns annehmen, das dies ein HTTP-0.9-Request für 

http://www.example.com/hello.txt wäre: 

Client-Request 

GET /hello.txt 

Server-Response 

Hello, world! 

Ein HTTP-Client arbeitet mit einer Ressource, indem er sich mit dem Server verbindet, 

der sie hostet (in diesem Fall www.example.com) und dem Server eine Methode 

(»GET«) sowie einen Pfad zur Ressource (»/hello.txt«) schickt. Das heutige HTTP 1. 

1 ist etwas komplexer als 0.9, funktioniert aber im Prinzip noch genauso. Sowohl der 

Server als auch der Pfad kommen aus dem URI der Ressource. 

Client-Request 

Server-Response 

Max. 

Linie 

GET /hello.txt HTTP/1.1 

Host: www.example.com 

200 OK 

Content-Type: text/plain 

Hello, world! 

Max. 

Linie 







Rechts 

Die Prinzipien hinter den URIs sind von Tim Berners-Lee sehr gut in »Universal 

Resource Identifiers – Axioms of Web Architecture« beschrieben (http://www.w3. 

org/DesignIssues/Axioms). In diesem Abschnitt möchte ich die Prinzipien vorstellen, 

die hinter dem Zusammenstellen von URIs und ihrer Zuweisung an Ressourcen stehen. 

Max. 

Linie 

Der URI ist die grundlegende Technologie des Web. Es gab schon 

vor HTML Hypertext-Systeme, und Internetprotokolle vor HTTP, 

aber sie konnten nicht miteinander sprechen. Der URI verband all 

diese Internetprotokolle zu einem Web, so wie TCP/IP die Netzwerke 

wie Usenet, Bitnet und CompuServe zu einem Internet vereint 

hat. Dann schluckte das Web diese anderen Protokolle und merzte 

sie aus, so wie es das Internet mit privaten Netzwerken tat. 

Heute surfen wir im Web (und nicht in Gopher), laden Dateien aus 

dem Web (und nicht von FTP-Sites), suchen Veröffentlichungen im 

Web (und nicht in WAIS) und reden miteinander im Web (und 

nicht in Usenet-Newsgroups). Versionsverwaltungssysteme wie Subversion 

und arch arbeiten über das Web – im Gegensatz zum CVS- 

Protokoll. Selbst E-Mails wandern langsam ins Web. 

Das Web merzt alle anderen Protokolle aus, weil es etwas hat, was 

den meisten Protokollen fehlt: eine einfache Möglichkeit, jedes verfügbare 

Element zu beschriften. Jede Ressource im Web hat mindestens 

einen URI. Sie können einen URI auf eine Reklametafel 

schreiben. Die Leute sehen diese Tafel, geben den URI in ihren Web- 

Browser ein und kommen direkt zu der Ressource, die Sie ihnen zeigen 

wollten. Es mag seltsam erscheinen, aber diese tagtägliche Interaktion 

war nicht möglich, bevor die URIs erfunden wurden. 

URIs sollten beschreibend sein 

Hier kommt der erste Punkt, bei dem die ROA auf den zurückhaltenden Empfehlungen 

des REST-Dokuments und der W3C-Empfehlungen aufbaut. Ich schlage vor, 

dass eine Ressource und ihr URI intuitiv zusammenpassen sollten. Hier sind ein paar 

gute URIs für die Ressourcen, die ich weiter oben aufgeführt habe: 

• http://www.example.com/software/releases/1.0.3.tar.gz 

• http://www.example.com/software/releases/latest.tar.gz 

• http://www.example.com/weblog/2006/10/24/0 

• http://www.example.com/landkarte/strassen/USA/AR/Little_Rock 

• http://www.example.com/wiki/Quallen 

• http://www.example.com/suche/Quallen 

• http://www.example.com/nextprime/1024 

• http://www.example.com/next-5-primes/1024 

• http://www.example.com/verkaeufe/2004/Q4 

Max. 

Linie 





Dieser Auszug unterliegt dem Urheberrecht. © O'Reilly Verlag 2008 

URIs | 93

• http://www.example.com/beziehungen/Alice;Bob 

• http://www.example.com/bugs/nach-zustand/open 

URIs sollten eine Struktur haben. Sie sollten vorhersehbar sein. Sie sollten nicht 

/suche/Quallen für Quallen und /i-want-to-know-about/Mäuse für Mäuse aufrufen 

müssen. Wenn ein Client die Struktur der URIs für die Services kennt, kann er seine 

eigenen Einstiegspunkte in den Service aufbauen. Das erleichtert es den Clients, 

Ihren Service auf Arten zu nutzen, die Sie gar nicht berücksichtigt haben. 

Das ist keine uneingeschränkt gültige Regel, wie wir im Abschnitt »Benennen der 

Ressourcen« auf Seite 133 sehen werden. URIs müssen technisch gesehen überhaupt 

keine Struktur haben oder vorhersehbar sein, aber ich denke, sie sollten es. Dies ist 

eine der Regeln guten Web-Designs, und sie zeigt sich sowohl bei REST-konformen 

als auch bei REST-RPC-Hybrid-Web Services. 

Links 

Max. 

Linie 

Die Beziehung zwischen URIs und Ressourcen 

Lassen Sie uns ein paar Grenzfälle betrachten. Können zwei Ressourcen gleich sein? 

Können zwei URIs die gleiche Ressource ansprechen? Kann ein einzelner URI zwei 

Ressourcen ansprechen? 

Per Definition können keine zwei Ressourcen gleich sein. Wenn sie es wären, wären 

Sie nur eine Ressource. Allerdings kann es Zeitenabschnitte geben, in denen zwei 

verschiedene Ressourcen auf die gleichen Daten verweisen. Wenn das aktuelle 

Software-Release die Version 1.0.3 ist, werden http://www.example.com/software/releases/1.0.3.tar.gz 

und http://www.example.com/software/releases/latest.tar.gz eine 

Zeit lang auf dieselbe Datei verweisen. Aber die Ideen hinter diesen beiden URIs sind 

verschieden: Eine wird immer auf eine bestimmte Version zeigen, während die 

andere auf das zeigt, was zum Zeitpunkt des Zugriffs die neueste Version ist. Das 

sind zwei Konzepte und zwei Ressourcen. Sie werden nicht auf latest verweisen, 

wenn Sie einen Fehler in Version 1.0.3 melden. 

Eine Ressource kann einen oder mehrere URIs haben. Die Verkaufszahlen, die unter 

http://www.example.com/sales/2004/Q4 verfügbar sind, lassen sich vielleicht auch 

über http://www.example.com/sales/Q42004 abrufen. Wenn eine Ressource mehrere 

URIs hat, ist es einfacher für die Clients, darauf zu verweisen. Als Nachteil mindert 

jeder weitere URI den Wert aller anderen. Manche Clients verwenden einen URI, 

manche einen anderen, und es gibt keine automatische Möglichkeit, zu überprüfen, 

ob all diese URIs auf die gleiche Ressource verweisen. 

Eine Möglichkeit, dies zu umgehen, ist es, mehrere URIs für die gleiche 

Ressource bereitzustellen, aber nur einen von ihnen als »kanonischen« 

URI für diese Ressource festzulegen. Wenn ein Client den 

kanonischen URI anfordert, schickt der Server die entsprechenden 

Daten zusammen mit dem Responsecode 200 (»OK«) zurück. For- 

Max. 

Linie 







Rechts 

dert ein Client einen der anderen URIs an, sendet der Server den 

Responsecode 303 (»See also«) zusammen mit dem kanonischen 

URI. Der Client kann nicht feststellen, ob zwei URIs auf die gleiche 

Ressource zeigen, aber er kann zwei HEAD-Requests abschicken und 

kontrollieren, ob ein URI zum anderen weiterleitet oder ob beide zu 

einem dritten URI verweisen. 

Man kann auch alle URIs gleich behandeln, aber der »kanonische« 

URI im Response-Header Content-Location immer dann angeben, 

wenn ein Request einen nicht kanonische URI anfordert. 

Max. 

Linie 

Der Aufruf von sales/2004/Q4 bringt Ihnen vielleicht den gleichen Bytestream wie 

sales/Q42004, da es sich um verschiedene URIs für dieselbe Ressource handelt: 

»Verkäufe im letzten Quartal 2004«. Der Aufruf von releases/1.0.3.tar.gz führt 

vielleicht zum selben Bytestream wie releases/latest.tar.gz, aber es handelt sich 

um unterschiedliche Ressourcen, die verschiedene Dinge repräsentieren: »Version 

1.0.3« und »die letzte Version«. 

Jeder URI bezeichnet exakt eine Ressource. Wenn er für mehr als eine Ressource 

stünde, wäre er kein Universal Resource Identifier. Aber wenn Sie einen URI 

abfragen, wird Ihnen der Server vielleicht Informationen über mehrere Ressourcen 

liefern: die eine, die Sie angefordert haben, und andere, die dazu in Beziehung stehen. 

Wenn Sie eine Web-Seite holen wollen, enthält diese normalerweise Informationen 

über sich selbst, aber auch Verweise auf andere Web-Seiten. Wenn Sie ein S3- 

Bucket mit einem Client für Amazons S3 laden, erhalten Sie ein Dokument, das 

Informationen über das Bucket, aber auch über dazu in Beziehung stehende 

Ressourcen enthält: die Objekte im Bucket. 

Adressierbarkeit 

Nachdem ich nun Ressourcen und ihre URIs eingeführt habe, kann ich zwei Features 

der ROA detaillierter behandeln: Adressierbarkeit und Zustandslosigkeit. 

Eine Anwendung ist dann adressierbar, wenn sie die interessanten Aspekte ihrer 

Daten als Ressourcen bereitstellt. Da Ressourcen durch URIs zur Verfügung gestellt 

werden, bietet eine adressierbare Anwendung eines URI für jedes Informationselement 

an, das sie eventuell herausgeben könnte. Das ist normalerweise eine 

unendlich große Zahl von URIs. 

Aus Sicht des Endanwenders ist die Adressierbarkeit der wichtigste Aspekt jeder 

Web-Site und Web-Anwendung. Benutzer sind schlau und ignorieren oder umgehen 

so gut wie jede Einschränkung, wenn die Daten nur interessant genug sind – aber es 

ist sehr schwer, fehlende Adressierbarkeit zu umgehen. 

Stellen Sie sich einen realen URI für eine Ressource »Verzeichnis der Ressourcen zu 

Quallen« http://www.google.com/search?q=Qualle vor. Diese Suche nach Quallen ist 

Max. 

Linie 

Adressierbarkeit | 95 






genauso real wie der URI http://www.google.com. Wenn HTTP nicht adressierbar 

oder die Such-Engine von Google keine adressierbare Web-Anwendung wäre, 

könnte ich diesen URI nicht in einem Buch veröffentlichen. Ich müsste Ihnen Folgendes 

erzählen: »Öffnen Sie eine Web-Verbindung zu google.com, geben Sie im 

Suchfeld ›Qualle‹ ein und klicken Sie dann auf den Button ›Google Search‹.« 

Links 

Das ist keine rein akademische Sorge. Bis Mitte der 90er Jahre, als 

URIs mit ftp:// beliebt wurden, um Dateien auf FTP-Sites zu 

beschreiben, mussten die Leute so ähnlich vorgehen: »Öffne eine 

anonyme FTP-Session auf ftp.example.com. Dann wechsle in das 

Verzeichnis pub/files/ und lade die Datei file.txt herunter.« URIs 

ermöglichten es, FTP genauso adressierbar zu machen wie HTTP. 

Jetzt schreiben die Leute einfach: »Lade die Datei ftp://ftp.example. 

com/pub/files/file.txt herunter.« Die Schritte sind die gleichen, sie 

können jetzt aber von einem Rechner durchgeführt werden. 

Max. 

Linie 

Aber HTTP und Google sind beide adressierbar, daher kann ich diesen URI in einem 

Buch angeben. Sie können sie lesen und eintippen. Wenn Sie das tun, landen Sie 

dort, wo ich auch war, als ich mit der Web-Anwendung von Google gearbeitet habe. 

Sie können dann diese Seite als Lesezeichen ablegen und sie später wieder besuchen. 

Sie können auf einer eigenen Web-Seite darauf verweisen. Sie können den URI an 

jemand anderen mailen. Wenn HTTP nicht adressierbar wäre, müssten Sie die ganze 

Seite herunterladen und die HTML-Datei als Anhang mitschicken. 

Um Bandbreite zu sparen, können Sie einen HTTP-Proxy-Cache in Ihrem lokalen 

Netzwerk einrichten. Wenn jemand das erste Mal http://www.google.com/ 

search?q=Qualle anfordert, speichert der Cache eine lokale Kopie des Dokuments. 

Wenn das nächste Mal jemand diesen URI eingibt, kann der Cache seine gespeicherte 

Kopie übermitteln, anstatt sie erneut herunterzuladen. All das ist nur möglich, 

wenn jede Seite einen eindeutigen String als Kennzeichen hat: eine Adresse. 

Es ist sogar möglich, URIs zu verketten, also einen URI als Eingabe für einen anderen 

zu verwenden. Sie können einen externen Web Service nutzen, um den HTML-Code 

einer Seite zu validieren, oder um den auf der Seite enthaltenen Text in eine andere 

Sprache zu übersetzen. Diese Web Services erwarten einen URI als Eingabe. Wenn 

HTTP nicht adressierbar wäre, hätten Sie keine Möglichkeit, ihnen mitzuteilen, mit 

welcher Ressource sie arbeiten sollen. 

Der S3-Service von Amazon ist adressierbar, weil jedes Bucket und jedes Objekt 

seinen eigenen URI besitzt, so wie auch die Bucket-Liste. Buckets und Objekte, die 

noch nicht existieren, sind noch keine Ressourcen, aber auch sie haben ihre eigenen 

URIs: Sie können eine Ressource erzeugen, indem Sie einen PUT-Request an ihren 

URI schicken. 

Das Dateisystem auf Ihrem eigenen Computer ist ein weiteres adressierbares System. 

Anwendungen an der Befehlszeile können einen Pfad zu einer Datei übernehmen 

Max. 

Linie 







Rechts 

und dann lustige Dinge damit anstellen. Die Felder in einer Tabellenkalkulation sind 

ebenfalls adressierbar – sie können den Namen eines Felds in eine Formel stecken, 

die dann den aktuellen Wert dieses Felds nutzen wird. URIs sind die Dateipfade und 

Feldadressen des Web. 

Adressierbarkeit ist eine der besten Eigenschaften von Web-Anwendungen. Sie erleichtert 

es Clients, Web-Sites anders zu nutzen, als sich das die ursprünglichen 

Designer überlegt hatten. Folgen Sie dieser einen Regel, bringt REST Ihnen und 

Ihren Anwendern viele Vorteile. Das ist der Grund, warum REST-RPC-Services so 

verbreitet sind: Sie kombinieren Adressierbarkeit mit dem Programmiermodell, in 

dem Prozeduren aufgerufen werden. Das ist der Grund, warum ich die Ressourcen 

so prominent in »ressourcenorientierter Architektur« stehen habe: weil sie die 

Dinger sind, die sich adressieren lassen. 

Das scheint ganz natürlich zu sein – die Art und Weise, wie das Web funktionieren 

sollte. Leider arbeiten viele Web-Anwendungen aber nicht so. Das gilt insbesondere 

für Ajax-Anwendungen. Wie ich in Kapitel 11 zeigen werden, sind die meisten Ajax- 

Anwendungen nur Clients für REST-konforme oder hybride Web Services. Aber 

wenn Sie diese Clients so nutzen, als ob es Web-Sites wären, werden Sie feststellen, 

dass sie sich nicht wie Web-Sites anfühlen. 

Lassen Sie uns nicht weiter darauf herumhacken, sondern unsere Reise zu den Google-Anwendungen 

fortführen, indem wir uns den Online-E-Mail-Service Google Mail 

anschauen. Aus Sicht des Endandwenders gibt es nur einen URI für Google Mail: 

https://mail.google.com/. Was auch immer Sie tun, welche Daten Sie auch von Google 

Mail laden oder dort ablegen – Sie werden niemals einen anderen URI zu Gesicht 

bekommen. Die Ressource »E-Mails zu Quallen« ist nicht adressierbar, wogegen es 

die »Web-Seiten über Quallen« von Google sind. 3 Aber wie ich in Kapitel 11 zeige, 

gibt es eine Web-Site, die adressierbar ist. Die Liste der E-Mails zum Thema Quallen 

hat einen URI: https://mail.google.com/mail/?q=Quallen&search=query&view=tl. Das 

Problem ist, dass Sie kein Benutzer dieser Web-Site sind. Die Site ist in Wirklichkeit 

ein Web Service, und der eigentliche Empfänger ist ein JavaScript-Programm, das 

innerhalb Ihres Web-Browsers läuft. 4 Der Web Service von Google Mail ist adressierbar, 

aber die Web-Anwendung von Google, die ihn nutzt, ist es nicht. 

Max. 

Linie 

3 Vergleichen Sie die Ajax-Schnittstelle mit der besser adressierbaren Version von Google Mail, die Sie 

erhalten, wenn Sie die Anwendung mit dem URI https://mail.google.com/mail/?ui=html aufrufen. Bei 

dieser Schnittstelle in klassischem HTML ist die Ressource »E-Mails zum Thema Quallen« adressierbar. 

4 Andere Konsumenten dieses Web Services nutzen die Bibliothek libgmail für Python (http://libgmail. 

sourceforge.net/). 

Max. 

Linie 

Adressierbarkeit | 97 






Max. 

Linie 

Zustandslosigkeit 

Adressierbarkeit ist eines der vier Hauptfeatures der ROA. Das zweite ist die 

Zustandslosigkeit. Ich werde Ihnen zwei Definitionen von Zustandslosigkeit geben: 

eine allgemeinere und eine praktischere, die zur ROA passt. 

Zustandslosigkeit bedeutet, dass jeder HTTP-Request in vollständiger Isolation 

geschieht. Wenn der Client einen HTTP-Request abschickt, enthält dieser alle Informationen, 

die für den Server notwendig sind, um die Anfrage zu erfüllen. Der Server 

verlässt sich niemals auf Informationen aus früheren Requests. Wenn solche Informationen 

wichtig gewesen wären, hätte der Client sie mit dem aktuellen Request 

erneut mitgeschickt. 

Wenn Sie das Ganze praktischer betrachten, stellen Sie sich die Zustandslosigkeit in 

Begriffen der Adressierbarkeit vor. Adressierbarkeit besagt, dass jede interessante 

Information, die der Server zur Verfügung stellen kann, auch als Ressource bereitstehen 

sollte und ihren eigenen URI bekommt. Zustandslosigkeit besagt, dass die 

möglichen Zustände des Servers ebenfalls Ressourcen sind und ebenso ihre eigenen 

URIs bekommen sollten. Der Client sollte den Server nicht in einen bestimmten 

Zustand zwingen müssen, damit er für eine bestimmte Anfrage empfänglich ist. 

Im menschlichen Web sehen Sie sich häufig Situationen gegenüber, in denen der 

»Zurück«-Button Ihres Browsers nicht richtig funktioniert und Sie in Ihrem Browser- 

Verlauf nicht vor- und zurückgehen können. Manchmal liegt das daran, dass Sie eine 

unwiderrufliche Aktion ausgelöst haben, wie zum Beispiel einen Weblog-Eintrag zu 

veröffentlichen oder ein Buch zu kaufen, aber häufig ist der Grund schlicht, dass eine 

Web-Site die Prinzipien der Zustandslosigkeit verletzt. Solch eine Site erwartet, dass 

Sie Anfragen in einer bestimmten Reihenfolge abschicken: A, B und dann C. Sie gerät 

durcheinander, wenn Sie Anfrage B ein zweites Mal abschicken, anstatt mit Anfrage 

C fortzufahren. 

Lassen Sie uns nochmals das Suchbeispiel nehmen. Eine Such-Engine ist ein Web 

Service mit einer unendlichen Zahl möglicher Zustände: Es gibt mindestens einen für 

jeden String, nach dem Sie suchen. Jeder Zustand hat seinen eigenen URI. Sie können 

den Service nach einem Verzeichnis mit Ressourcen über Mäuse fragen: http:// 

www.google.com/search?q=M%E4use. Sie können nach einem Verzeichnis mit 

Ressourcen über Quallen fragen: http://www.google.com/search?q=Quallen. Wenn 

Sie sich nicht sicher sind, wie man einen URI vollständig selber erstellt, können Sie 

den Service nach einem Formular dafür fragen: http://www.google.com/. 

Wenn Sie nach einem Verzeichnis der Ressourcen zu Mäusen oder Quallen fragen, 

erhalten Sie nicht das gesamte Verzeichnis. Sie bekommen eine einzelne Seite des 

Verzeichnisses: eine Liste mit (zum Beispiel) zehn Ressourcen, die nach Ansicht der 

Such-Engine Ihre Anfrage am Besten beantworten. Um mehr zu bekommen, müssen 

Sie zusätzliche HTTP-Requests absetzen. Die zweite und die folgenden Seiten sind 

Links 

Max. 

Linie 







Rechts 

eigene Zustände der Anwendung und müssen ihre eigenen URIs haben, zum Beispiel 

http://www.google.com/search?q=Quallen&start=10. Wie bei jeder adressierbaren 

Ressource können Sie diesen Zustand der Anwendung an jemand anderen übermitteln, 

ihn zwischenspeichern oder zu Ihren Lesezeichen stecken und später dorthin 

zurückkehren. 

Abbildung 4-1 ist ein einfaches Zustandsdiagramm, das zeigt, wie ein HTTP-Client 

mit vier Zuständen einer Such-Engine interagieren könnte. 

Such-Formular 

“Quallen” 

Request 

Request 

Response 

Response 

Response 

Initialer Zustand 

“Mäuse”, 

Seite 2 

Request 

Response 

“Mäuse” 

Request 

Abbildung 4-1: Eine zustandslose Such-Engine 

Dies ist eine zustandslose Anwendung, weil bei jedem Zugriff, den ein Client tätigt, 

wieder von vorn angefangen wird. Jeder Request ist völlig unabhängig von den 

anderen. Der Client kann Anfragen an diese Ressourcen beliebig häufig vornehmen 

und in beliebiger Reihenfolge. Er kann Seite 2 über »Mäuse« aufrufen, bevor er Seite 

1 anfordert (oder Seite 1 völlig ignorieren) – den Server wird es nicht kümmern. 

Im totalen Gegensatz dazu zeigt Abbildung 4-2 die gleichen Zustände, nun zustandsbehaftet 

angeordnet, wobei die Zustände sinnvoll ineinander übergehen können. 

Die meisten Desktop-Anwendungen sind so entworfen. 

Initialer Zustand 

Such-Formular 

“Mäuse” 

“Quallen” 

Max. 

Linie 

Abbildung 4-2: Eine zustandsbehaftete Such-Engine 

“Mäuse”, 

Seite 2 

Max. 

Linie 

Zustandslosigkeit | 99 






Max. 

Linie 

Das ist deutlich besser organisiert, und wenn HTTP so entworfen wäre, dass es 

zustandsbehaftete Interaktionen zulassen würde, könnten HTTP-Requests deutlich 

einfacher sein. Wenn der Client eine Session mit der Such-Engine starten würde, 

könnte er automatisch das Suchformular ausfüllen. Er müsste keinerlei Request- 

Daten schicken, da die erste Response vorherbestimmt wäre. Wenn der Client sich 

die ersten zehn Einträge im Mäuse-Verzeichnis angeschaut hätte und nun die Einträge 

11–20 sehen wollte, müsste er nur einen Request mit dem Inhalt »start=10« 

schicken. Er müsste nicht nach /search?q=mice&start=10 fragen und damit die initialen 

Vorgaben wiederholen: »Ich suche, und zwar speziell nach Mäusen.« 

Genau so funktioniert FTP: Es kennt ein »Arbeitsverzeichnis«, das während der gesamten 

Sitzung konstant bleibt, sofern Sie es nicht ändern. Sie können sich an einem 

FTP-Server anmelden, per cd zu einem bestimmten Verzeichnis wechseln und per 

get eine Datei aus diesem Verzeichnis holen. Dann nutzen Sie get erneut für eine 

andere Datei aus demselben Verzeichnis, ohne einen zweiten cd-Befehl ausführen zu 

müssen. Warum unterstützt HTTP das nicht? 

Zustände würden einzelne HTTP-Anfragen vereinfachen, aber das HTTP-Protokoll 

deutlich verkomplizieren. Ein FTP-Client ist weitaus komplizierter als ein HTTP- 

Client, und zwar genau aus dem Grund, dass der Session-Zustand zwischen Client 

und Server synchron gehalten werden muss. Das ist eine komplexe Aufgabe selbst in 

einem stabilen Netzwerk, was das Internet definitiv nicht ist. 

Eliminiert man den Zustand aus einem Protokoll, eliminiert man auch eine Reihe 

von Fehlerquellen. Der Server muss sich keine Sorgen um das Timeout eines Clients 

machen, da keine Interaktion länger als ein einzelner Request dauert. Der Server verliert 

nie die Übersicht darüber, »wo« sich jeder Client in der Anwendung befindet, da 

der Client alle notwendigen Informationen mit jeder Anfrage mitschickt. Der Client 

führt nie eine Aktion im falschen »Arbeitsverzeichnis« aus, nur weil der Server einen 

Zustand geändert hat, ohne es dem Client zu erzählen. 

Zustandslosigkeit bringt auch neue Features mit. Es ist einfacher, eine zustandslose 

Anwendung zum Lastausgleich auf mehrere Server zu verteilen. Da keine zwei 

Requests voneinander abhängig sind, können sie von zwei verschiedenen Servern 

verarbeitet werden, die sich nicht gegenseitig koordinieren müssen. Skalieren ist einfach: 

Man muss dem Load Balancer nur weitere Server hinzufügen. Eine zustandslose 

Anwendung lässt sich auch einfach cachen: Eine Software kann entscheiden, ob 

die Ergebnisse eines HTTP-Request gecachet werden können, indem nur der 

entsprechende Request angeschaut wird. Es gibt keine quälende Unsicherheit, ob 

der Zustand aus einer vorigen Anfrage die Cachebarkeit der aktuellen Anfrage beeinflusst. 

Der Client zieht aus der Zustandslosigkeit ebenfalls Vorteile. Ein Client kann das 

Mäuse-Verzeichnis ab Seite 50 verarbeiten, ein Lesezeichen für /search?q= 

Mäuse&start=500 speichern und eine Woche später wiederkommen, ohne sich durch 

Dutzende von vorigen Zuständen durcharbeiten zu müssen. Ein URI, der mitten 

Links 

Max. 

Linie 







Rechts 

Max. 

Linie 

während einer langen HTTP-Sitzung abgesetzt wird, funktioniert genauso, als ob er als 

erster URI in einer neuen Session angefragt wird. 

Um Ihren Service adressierbar zu machen, müssen Sie ein wenig Aufwand treiben 

und die Daten Ihrer Anwendung in Ressourcen aufteilen. HTTP ist schon an sich ein 

zustandsloses Protokoll, daher erhalten Sie die Zustandslosigkeit automatisch, wenn 

Sie Web Services schreiben. Um das zu ändern, müssen Sie etwas tun. 

Um die Zustandslosigkeit aufzuheben, nutzen Sie am besten HTTP-Sessions, die von 

Ihrem Framework unterstützt werden. Sobald sich ein Benutzer auf Ihre Seiten begibt, 

erhält er einen eindeutigen String, der seine Session auf der Site identifiziert. 

Der String kann sich in einem Cookie befinden, oder die Site reicht den String in 

allen URIs weiter, die sie einem bestimmten Client zur Verfügung stellt. So sieht ein 

Session-Cookie aus, das von einer Rails-Anwendung gesetzt wurde: 

Set-Cookie: _session_id=c1c934bbe6168dcb904d21a7f5644a2d; path=/ 

Dieser URI gibt die Session-ID in einer PHP-Anwendung weiter: http://www.example.com/forums?PHPSESSID=27314962133. 

Wichtig zu beachten ist dabei, das unsinnige hexadezimale oder dezimale Zahlen 

kein Zustand sind. Es handelt sich um einen Schlüssel zu einer Datenstruktur auf 

dem Server, und diese Datenstruktur enthält den Zustand. An zustandsbehafteten 

URIs gibt es nichts, was REST widerspricht: So kommuniziert der Server mögliche 

nächste Zustände an den Client weiter. (Aber Cookies sind nicht REST-konform, 

wie ich in Abschnitt »Ärger mit Cookies« auf Seite 286 besprechen werde. Um eine 

Web-Browser-Analogie zu verwenden: Cookies machen den »Zurück«-Button in 

einem Client für einen Web Service kaputt.) 

Betrachten Sie einmal die Query-Variable start=10 in einem URI, der in einer 

HTML-Seite eingebettet ist, die durch die Such-Engine von Google ausgeliefert 

wurde. Damit schickt der Server einen möglichen nächsten Zustand an den Client. 

Aber solche URIs müssen den Zustand enthalten und nicht nur einen Schlüssel zu 

einem Zustand liefern, der auf dem Server abgelegt ist. start=10 hat von sich aus 

Bedeutung, was bei PHPSESSID=27314962133 nicht der Fall ist. REST-konform zu sein 

erfordert, dass der Zustand auf Client-Seite vorhanden bleibt und an den Server bei 

jedem Request geschickt wird, der dies erfordert. Der Server kann den Client zu 

neuen Zuständen drängen, indem er zustandsbehaftete Verweise schickt, denen der 

Client folgen kann, aber er kann den Status nicht selber verwalten. 

Anwendungszustand vs. Ressourcen-Zustand 

Wenn wir uns über »Zustandslosigkeit« unterhalten, müssen wir uns fragen, was ein 

»Zustand« ist. Was ist der Unterschied zwischen persistenten Daten, also den nützlichen 

Daten auf Serverseite, wegen derer wir den Web Service vor allem nutzen, und 

diesem Zustand, den wir vom Server fern halten wollen? Der Flickr-Web Service lässt 

Max. 

Linie 

Zustandslosigkeit | 101 






Max. 

Linie 

Sie Bilder auf Ihr Konto hochladen, die dann auf dem Server gespeichert werden. Es 

wäre verrückt, den Client jedes seiner Bilder zusammen mit jedem Request an 

flickr.com schicken zu lassen, nur um den Server davon abzuhalten, irgendeinen 

Zustand speichern zu müssen. Das würde den ganzen Service ad absurdum führen. 

Aber was ist dann der Unterschied zwischen diesem Szenario und dem Zustand der 

Client-Session, von dem ich fordere, dass er vom Server fernbleibt? 

Das Problem liegt in der Terminologie. Zustandslosigkeit impliziert, dass es nur eine 

Art von Zustand gibt und dass der Server sich davon fernhalten sollte. Tatsächlich 

gibt es zwei Zustandsarten. Ich werde in diesem Buch von nun an zwischen dem 

Anwendungszustand, der auf dem Client, und dem Ressourcen-Zustand, der auf dem 

Server verwaltet werden sollte, unterscheiden. 

Wenn Sie eine Such-Engine verwenden, sind Ihre aktuelle Abfrage und die aktuelle 

Seite Teile des Anwendungszustands. Dieser Zustand unterscheidet sich für jeden 

Client. Sie können sich auf Seite 3 der Suchergebnisse für »Quallen« befinden, 

während ich mich auf Seite 1 der Suchergebnisse für »Mäuse« tummle. Die Seitennummer 

und die Abfrage sind verschieden, da wir unterschiedliche Pfade in der 

Anwendung eingeschlagen haben. Unsere jeweiligen Clients verwalten unterschiedliche 

Anwendungszustände. 

Ein Web Service muss sich nur dann um Ihren Anwendungszustand kümmern, 

wenn Sie tatsächlich einen Request stellen. Den Rest der Zeit weiß er nicht einmal, 

dass Sie existieren. Das bedeutet, dass immer dann, wenn ein Client einen Request 

absetzt, dieser alle Anwendungszustände enthält, die der Server benötigt, um die 

Anfrage zu verarbeiten. Es kann sein, dass der Server eine Seite mit Verweisen 

zurückschickt, die den Client über andere Requests informieren, die er in Zukunft 

stellen könnte. Aber danach kann er wieder alles vergessen, was er über den Client 

weiß, bis dieser die nächste Anfrage stellt. Das meine ich, wenn ich sage, dass ein 

Web Service »zustandslos« sein sollte. Der Client sollte dafür verantwortlich sein, 

seinen eigenen Weg durch die Anwendung selbst zu verwalten. 

Der Ressourcen-Zustand ist für jeden Client gleich, und sein Platz ist auf dem Server. 

Wenn Sie ein Bild in Flickr hochladen, erzeugen Sie eine neue Ressource: Das neue 

Bild hat seinen eigenen URI und kann das Ziel zukünftiger Requests sein. Sie können 

die Ressource »Bild« per HTTP laden, verändern und löschen. Jeder kann das tun. 

Das Bild ist ein Teil des Ressourcen-Zustands und bleibt auf dem Server, bis ein 

Client es löscht. 

Der Client-Zustand kann an Stellen auftauchen, an denen Sie ihn nicht erwarten 

würden. Viele Web Services wollen eine Registrierung, nach der Sie einen eindeutigen 

String erhalten (meist als API-Key oder Application Key bezeichnet). Sie 

schicken diesen Schlüssel bei jedem Request mit, und der Server verwendet ihn, um 

Ihre Anfragen auf eine bestimmte Obergrenze pro Tag einzuschränken. So ist zum 

Beispiel ein API Key für Googles auslaufende SOAP-Such-API für 1000 Requests pro 

Links 

Max. 

Linie 







Rechts 

Max. 

Linie 

Tag gut. Das ist ein Anwendungszustand: Er unterscheidet sich für jeden Client. 

Nachdem Sie das Limit überschritten haben, ändert sich das Verhalten des Service 

drastisch: Bei Anfrage 1000 erhalten Sie Ihre Daten, bei Anfrage 1001 nur eine 

Fehlermeldung. Im Moment bin ich bei Anfrage 402, und der Service funktioniert für 

mich klasse. 

Natürlich kann man Clients nicht vertrauen, dieses Element des Anwendungszustands 

selbst zu verwalten: Die Versuchung zu schummeln, ist zu groß. Daher 

behalten Server diese Art von Anwendungszustand bei sich und verletzen damit das 

Prinzip der Zustandslosigkeit. Der API Key ist wie das Rails-Cookie _session_id ein 

Schlüssel für eine Client-Session auf Server-Seite, die einen Tag anhält. Das ist soweit 

vertretbar, man muss aber bei der Skalierbarkeit einen Preis dafür zahlen. Wenn der 

Service über mehrere Maschinen verteilt wird, muss jeder Rechner im Cluster wissen, 

dass Sie schon Request 1001 geschickt haben, während ich noch bei Nummer 

402 bin (der technische Begriff dafür ist die Session Replication), so dass jede 

Maschine weiß, dass sie Ihren Zugriff abblocken und meinen bearbeiten soll. Alternativ 

dazu muss der Load Balancer sicherstellen, dass jeder Ihrer Requests auf der 

gleichen Maschine im Cluster verarbeitet wird (Session Affinity). Durch Zustandslosigkeit 

entfällt diese Anforderung. Als Servicedesigner müssen Sie über Datenreplikation 

nur nachdenken, wenn Ihr Ressourcen-Zustand über mehrere Rechner 

verteilt werden muss. 

Repräsentationen 

Wenn Sie Ihre Anwendung in Ressourcen aufteilen, vergrößern Sie den Bereich, der 

nach außen hin sichtbar ist. Ihre Anwender können sich passende URIs bauen und in 

Ihre Anwendung genau dort einsteigen, wo sie es brauchen. Aber die Ressourcen 

sind nicht die Daten, sondern nur die Idee des Servicedesigners, wie die Daten in 

»eine Liste offener Bugs« oder »Informationen über Quallen« unterteilt werden. Ein 

Web-Server kann keine Ideen senden, er muss eine Abfolge von Bytes in einem 

bestimmten Dateiformat und einer bestimmten Sprache schicken. Das ist eine 

Repräsentation der Ressource. 

Eine Ressource ist eine Quelle für Repräsentationen, und eine Repräsentation 

besteht einfach aus Daten zum aktuellen Zustand einer Ressource. Die meisten Ressourcen 

sind selbst Daten (wie zum Beispiel eine Liste mit Fehlern), daher sind die 

Daten selbst eine offensichtliche Repräsentation einer Ressource. Der Server kann 

eine Liste mit ungelösten Fehlern als XML-Dokument, als Web-Seite oder als kommaseparierten 

Text ausgeben. Die Verkaufszahlen für das letzte Quartal 2004 können 

numerisch oder als Diagramm ausgegeben werden. Viele News-Sites stellen ihre 

Artikel in einem mit Werbung gespickten Format und in einem »druckerfreundlichen« 

reduzierten Format bereit. Es handelt sich immer um verschiedene Repräsentationen 

der gleichen Ressourcen. 

Max. 

Linie 

Repräsentationen | 103 






Aber manche Ressourcen repräsentieren physikalische Objekte oder andere Dinge, 

die nicht auf Informationen reduziert werden können. Was kann man da als gute 

Repräsentation verwenden? Sie müssen sich keine Sorgen um eine perfekte Widergabe 

machen: Eine Repräsentation ist jede nützliche Information über den Zustand 

einer Ressource. 

Stellen Sie sich ein physikalisches Objekt vor – z.B. einen Getränkeautomaten –, der 

mit einem Web Service verbunden ist. 5 Ziel ist, den Nutzern des Automaten 

unnötige Wege dorthin zu ersparen. Durch diesen Service können die Leute wissen, 

ob die Getränke kalt sind oder die bevorzugte Marke ausverkauft. Keiner erwartet, 

dass die realen Getränkedosen über den Web Service zur Verfügung stehen, da physische 

Objekte keine Daten sind. Aber es gibt Daten über sie: Metadaten. Jeder 

Schacht im Automaten kann mit einem Kästchen versehen werden, das über die 

Sorte, den Preis und die Temperatur der nächsten verfügbaren Dose Bescheid weiß. 

Die Metadaten dieser Geräte können in den Repräsentationen der Ressourcen verwendet 

werden. 

Selbst wenn eine der Repräsentationen eines Objekts die eigentlichen Daten enthält, 

kann es auch Repräsentationen geben, in denen sich Metadaten finden. Eine 

Onlinebuchhandlung kann zum Beispiel zwei Repräsentationen eines Buchs bereitstellen: 

1. Eine enthält nur Metadaten, wie zum Beispiel ein Bild des Titels und Reviews, 

mit denen das Buch beworben wird. 

2. Eine elektronische Variante der Daten im Buch, die Sie via HTTP erhalten, 

wenn Sie dafür zahlen. 

Repräsentationen funktionieren aber auch andersherum. Sie können eine Repräsentation 

einer neuen Ressource an den Server schicken, damit dort die Ressource 

erzeugt wird. Das geschieht, wenn Sie bei Flickr ein Bild hochladen. Oder Sie können 

dem Server eine neue Repräsentation einer bestehenden Ressource zukommen lassen 

und dadurch den Server die Ressource ändern lassen, damit sie mit der neuen 

Repräsentation im Einklang steht. 

Links 

Sich zwischen Repräsentationen entscheiden 

Wenn ein Server mehrere Repräsentationen einer Ressource anbietet, stellt sich die 

Frage, wie er herausfindet, nach welcher der Client fragt. So kann eine Pressemitteilung 

zum Beispiel sowohl auf Deutsch als auch auf Englisch veröffentlicht worden 

sein. Welche will ein bestimmter Client dann haben? 

Max. 

Linie 

5 Die Idee basiert auf dem CMU-Cola-Automaten (http://www.cs.cmu.edu/%7Ecoke/), der viele Jahre lang 

»beobachtet« wurde und dessen jeweiliger Status über das Finger-Protokoll abgefragt werden konnte. 

Der Automat existiert immer noch, allerdings war der Status beim Schreiben dieses Buchs nicht online 

abfragbar. 

Max. 

Linie 







Rechts 

Es gibt eine Reihe von Möglichkeiten, das innerhalb der Grenzen von REST herauszufinden. 

Der einfachste – und die, die ich für die ressourcenorientierte Architektur 

empfehle – ist ein eigener URI für jede Repräsentation einer Ressource. http://www. 

example.com/releases/104.de könnte für die deutsche Repräsentation der Pressemitteilung 

stehen und http://www.example.com/releases/104.en für die englische. 

Ich empfehle diese Technik für ROA-Anwendungen, weil der URI damit alle Informationen 

enthält, die der Server zum Beantworten des Requests benötigt. Der 

Nachteil bei der Bereitstellung von mehreren URIs für die gleiche Ressource ist eine 

Abschwächung: Leute, die über die Pressemitteilung in verschiedenen Sprachen 

reden, scheinen über unterschiedliche Dinge zu sprechen. Sie können das etwas 

abmildern, indem Sie den URI http://www.example.com/releases/104 anbieten, mit 

dem die Mitteilung in einer übergreifenden Form gemeint ist, unabhängig von einer 

Sprache. 

Eine Alternative wird als Content Negotiation bezeichnet. In diesem Szenario wird 

nur der übergreifende URI http://www.example.com/releases/104 veröffentlicht. 

Wenn ein Client einen Request für diesen URI abschickt, enthält er bestimmte 

HTTP-Request-Header, die anzeigen, was für eine Art von Repräsentation der Client 

akzeptieren wird. 

Ihr Web-Browser hat eine Einstellung für die Sprache: Dort können Sie festlegen, in 

welcher Sprache die Web-Seiten erscheinen sollen. Der Browser schickt diese Information 

mit jedem HTTP-Request im Header Accept-Language mit. Der Server ignoriert 

diese Information meist, da der Großteil der Web-Seiten nur in einer Sprache 

zur Verfügung steht. Aber es passt genau zu dem, was wir hier versuchen: Repräsentationen 

der gleichen Ressource in verschiedenen Sprachen bereitzustellen. Wenn 

ein Client http://www.example.com/releases/104 anfordert, kann der Server abhängig 

vom Header Accept-Language des Clients entscheiden, ob er die deutsche oder die 

englische Repräsentation ausliefert. 

Die Such-Engine von Google ist ein guter Ort, das auszuprobieren. 

Sie können Ihre Suchergebnisse in so gut wie jeder Sprache präsentiert 

bekommen, indem Sie die Spracheinstellungen Ihres Browsers 

ändern oder die Query-Variable hl in dem URI anpassen (zum Beispiel 

hl=tr für türkisch). Die Such-Engine unterstützt sowohl Content 

Negotiation als auch verschiedene URIs für unterschiedliche 

Repräsentationen. 

Max. 

Linie 

Ein Client kann auch den Header Accept setzen, um anzugeben, welches Dateiformat 

er für die Repräsentation bevorzugt. Er kann sagen, dass er lieber XHTML als 

HTML oder SVG als ein anderes Grafikformat haben möchte. 

Der Server kann alle diese Request-Metadaten nutzen, um zu entscheiden, welche 

Repräsentation er schickt. Andere mögliche Metadaten dazu sind Bezahlinformationen, 

Authentifizierungs-Credentials, der Zeitpunkt des Requests, Caching- 

Max. 

Linie 

Repräsentationen | 105 






Max. 

Linie 

Anweisungen und selbst die IP-Adresse des Clients. All diese Daten können in die 

Entscheidungsfindung des Servers einfließen, welche Daten in der Repräsentation 

enthalten sein sollen, welche Sprache und welches Format genutzt wird und sogar, 

ob überhaupt eine Repräsentation geschickt oder der Zugriff verweigert wird. 

Es ist REST-konform, diese Information in den HTTP-Headern zu speichern, und es 

ist auch REST-konform, sie in den URI zu stecken. Ich empfehle, so viele dieser 

Informationen wie möglich in den URI zu packen und so wenige wie möglich in die 

Metadaten des Requests. Ich denke, URIs sind nützlicher als Metadaten. URIs werden 

von Person zu Person und von Programm zu Programm weitergereicht. Die 

Metadaten des Requests gehen dabei aber so gut wie immer verloren. 

Ein einfaches Beispiel für dieses Dilemma ist der W3C-HTML-Validator, ein Web 

Service, der unter http://validator.w3.org/ zur Verfügung steht. So sieht ein URI zu 

einer Ressource auf der Site des W3C aus, ein Validationsreport der deutschen Version 

meiner hypothetischen Pressemitteilung: http://validator.w3.org/check?uri= 

http%3A%2F%2Fwww.example.com%2Freleases%2F104.de. 

So sieht eine andere Ressource aus, ein Validationsreport der englischen Version der 

Pressemitteilung: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.example. 

com%2Freleases%2F104.en. 

Jeder URI in Ihrem Web-Space wird zu einer Ressource in der Web-Anwendung des 

W3C, egal ob es zu einer eigenständigen Ressource auf Ihrer Site verweist. Wenn 

Ihre Pressemitteilung einen eigenen URI für jede Repräsentation hat, können Sie 

zwei Ressourcen vom W3C bekommen: Validationsreporte für die deutsche und die 

englische Version der Pressemitteilung. 

Aber wenn Sie nur die übergreifende Form des URI herausgeben und beide Repräsentationen 

über diesen URI anbieten, können Sie vom W3C nur eine Ressource bekommen. 

Das wäre ein Validationsreport für die Standardversion der Pressemitteilung 

(vermutlich die deutsche). Sie haben keine Möglichkeit herauszufinden, ob die 

englische Repräsentation HTML-Formatierungsfehler enthält. Wenn der Server die 

englische Pressemitteilung nicht als eigenen URI bereitstellt, gibt es keine entsprechende 

Ressource auf der W3C-Site. Das bedeutet nicht, dass Sie den übergreifenden 

URI nicht anbieten sollten – es sollte nur nicht der einzige URI sein, dene Sie nutzen. 

Anders als Menschen sind Computerprogramme sehr schlecht im Umgang mit 

Repräsentationen, die sie nicht erwarten. Ich denke, dass ein automatisierter Web- 

Client so explizit wie möglich sein sollte, wenn er die Repräsentation beschreibt, die er 

haben möchte. Das bedeutet so gut wie immer, dass sie in dem URI spezifiziert wird. 

Verweise und Verbindungshaftigkeit 

Manchmal sind Repräsentationen nicht viel mehr als serialisierte Datenstrukturen. 

Sie sind dazu gedacht, ihrer Daten beraubt und dann weggeworfen zu werden. Aber 

Links 

Max. 

Linie 







Rechts 

in den meisten REST-konformen Services sind Repräsentationen Übermedien: 

Dokumente, die nicht nur Daten enthalten, sondern auch Verweise auf andere Ressourcen. 

Nehmen wir uns wieder das Suchbeispiel vor. Wenn Sie zu Googles Verzeichnis der 

Dokumente über Quallen gehen (http://www.google.com/search?q=Quallen), erhalten 

Sie ein paar Suchergebnisse und eine Reihe interner Verweise auf andere Seite 

des Verzeichnisses. Abbildung 4-3 zeigt einen passenden Ausschnitt aus der Seite. 

Teil des Verzeichnisses 

Max. 

Linie 

Abbildung 4-3: Ausschnitt einer Seite mit Suchergebnissen bei Google 

Interne Verzeichnis-Verweise 

Es gibt hier Daten und Verweise. Die Daten sagen aus, dass es irgendwo im Web 

irgendetwas gibt, das irgendwer über Quallen geschrieben hat. Die Verweise 

ermöglichen Ihnen Zugriff auf andere Ressourcen: manche innerhalb des »Web Service« 

von Google, andere irgendwo anders im Web: 

• Die externe Webseite, die sich mit Quallen befasst: http://de.wikipedia.org/wiki/ 

Qualle. Hauptaufgabe dieses Web Service ist natürlich, solche Verweise zu präsentieren. 

• Ein Verweis auf einen von Google bereitgestellten Cache der externen Seite 

(der Verweis »Cached«). Diese Verweise haben immer lange URIs, die auf 

Google-eigene IP-Adressen zeigen, zum Beispiel http://209.85.135.104/search?q 

=cache:nZOeteMPBM... 

• Ein Verweis auf ein Verzeichnis mit Seiten, von denen Google denkt, dass sie 

zu der externen Seite in Beziehung stehen (http://www.google.com/search?hl= 

en&q=related:de.wikipedia.org/wiki/Qualle, bezeichnet als »Similar pages«). 

Das ist ein weiterer Fall eines Web Service, der einen URI als Eingabewert 

nutzt. 

• Eine Reihe von Navigationsverweisen, die Sie zu verschiedenen Seiten des 

Quallen-Verzeichnisses führen: http://www.google.com/search?q=Quallen&start 

=10, http://www.google.com/search?q=Quallen&start=20 und so weiter. 

Max. 

Linie 



| 107 





Max. 

Linie 

Weiter oben in diesem Kapitel habe ich gezeigt, was passieren könnte, wenn HTTP 

ein zustandsbehaftetes Protokoll wie FTP wäre. Abbildung 4-2 zeigt den Weg, den 

ein zustandsbehafteter HTTP-Client während einer »Session« mit www.google.com 

nehmen könnte. HTTP funktioniert so natürlich nicht, aber die Abbildung zeigt 

ganz gut, wie wir das menschliche Web nutzen. Für die Nutzung einer Such-Engine 

beginnen wir auf der Homepage, tragen in ein Formular ihren Suchwunsch ein und 

klicken dann auf die Verweise, um die verschiedenen Ergebnisseiten zu erhalten. Wir 

tippen normalerweise nicht andauernd URIs ein – stattdessen folgen wir Verweisen 

und füllen Formulare aus. 

Wenn Sie schon vorher etwas über REST gelesen haben, ist Ihnen vielleicht ein 

Axiom aus der Dissertation von Fielding über den Weg gelaufen: »Übermedien als 

treibende Kraft des Anwendungszustands.« Das Axiom bedeutet, dass der aktuelle 

Zustand einer HTTP-»Session« nicht auf dem Server als Ressourcen-Zustand gespeichert, 

sondern vom Client als Anwendungszustand verfolgt und durch den Pfad 

erzeugt wird, den der Client im Web beschreitet. Der Server leitet den Client auf 

seinem Weg, indem er ihm »Übermedien« anbietet: Verweise und Formulare innerhalb 

einer Hypertext-Repräsentation. 

Der Server schickt dem Client Hilfestellungen, welche Zustände vom aktuellen aus 

gut erreicht werden können. Der Verweis »Next« auf http://www.google.com/ 

search?q=Quallen ist ein Zustandswegweiser: Er zeigt Ihnen, wie Sie vom aktuellen 

Zustand zu einem damit verbundenen Zustand kommen. Das eröffnet viele Möglichkeiten. 

Ein Dokument, das einen URI enthält, verweist auf einen anderen möglichen 

Zustand der Anwendung: »Seite 2«, »Ähnlich wie dieser URI« oder »eine 

gecachete Version dieses URI«. Oder es verweist damit auf einen möglichen Zustand 

einer völlig anderen Anwendung. 

Ich nenne die Möglichkeit,Verweise zu enthalten, Verbindungshaftigkeit. Ein Web 

Service ist insoweit verbunden, als Sie den Service in verschiedene Zustände bringen 

können, indem Sie einfach Verweisen folgen und Formulare ausfüllen. Den Begriff 

»Verbindungshaftigkeit« nutze ich, weil »Übermedien als treibende Kraft des 

Anwendungszustands« das Konzept komplizierter klingen lässt als es ist. Ich will nur 

sagen, dass Ressourcen in ihren Repräsentationen miteinander verknüpft sein sollen. 

Das menschliche Web ist einfach zu nutzen, weil es so gut vernetzt ist. Jeder erfahrenere 

Anwender weiß, wie man URIs in die Adressleiste des Browsers eingibt und wie man auf 

einer Site herumspringen kann, indem man die URI verändert, aber viele Benutzer surfen 

im Web nur von einem einzigen Startpunkt aus: der Homepage des Browsers, die 

durch ihren ISP eingerichtet wurde. Das ist deshalb möglich, weil das Web so gut vernetzt 

ist. Seiten verweisen aufeinander, selbst über Site-Grenzen hinweg. 

Die meisten Web Services sind aber nicht einmal intern vernetzt, ganz zu schweigen 

von Verbindungen zu anderen Services. Amazon S3 ist ein REST-konformer Web 

Service, der adressierbar und zustandslos ist, aber nicht vernetzt. S3-Repräsenta- 

Links 

Max. 

Linie 







Rechts 

tionen enthalten niemals URIs. Um ein S3-Bucket per GET zu erhalten, müssen Sie 

die Regeln kennen, wie der URI des Buckets aufgebaut wird. Sie können nicht einfach 

per GET die Bucket-Liste holen und dann einem Verweis zu dem Bucket folgen, 

das Sie brauchen. 

Beispiel 4-1 zeigt eine S3-Bucket-Liste, die ich geändert habe (durch ein zusätzliches 

Tag URI), damit sie verbindungsbehaftet ist. Vergleichen Sie das mit Beispiel 3-5, das 

kein solches Tag besitzt. Das ist nur eine Möglichkeit, URIs in eine XML-Repräsentation 

einzuführen. Wenn Ressourcen besser miteinander verbunden werden, werden 

auch die Beziehungen zwischen ihnen offensichtlicher (siehe Abbildung 4-4). 

Beispiel 4-1: Eine verbindungshaftige »Liste Ihrer Buckets« 

 

 

 

c0363f7260f2f5fcf38d48039f4fb5cab21b060577817310be5170e7774aad70 

leonardr28 

 

 

 

crummy.com 

https://s3.amazonaws.com/crummy.com 

2006-10-26T18:46:45.000Z 

 

 

 

Max. 

Linie 

a b c 

Alle drei Services bieten die gleiche Funktionalität an, aber ihr Nutzen steigert sich von links nach rechts. 

• Service A ist ein typischer Service im RPC-Stil, denn alles wird über eine einzelne URI angeboten. 

Er ist weder adressierbar noch verbunden. 

• Service B ist adressierbar, aber nicht verbunden: Es gibt keine Hinweise auf die Beziehungen zwischen 

den Ressourcen. Das kann ein REST-RPC-Hybrid sein oder ein REST-konformer Service wie Amazon S3. 

• Service C ist adressierbar und gut verbunden: Ressourcen sind (vermutlich) sinnvoll miteinander 

verknüpft. Das könnte ein vollständiger REST-konformer Service sein. 

Abbildung 4-4: Ein Service auf drei Wegen 

Max. 

Linie 



| 109 





Max. 

Linie 

Die einheitliche Schnittstelle 

Im ganzen Web gibt es nur ein paar Dinge, die Sie mit einer Ressource anstellen können. 

HTTP stellt vier grundlegende Methoden für die gebräuchlichsten Operationen 

bereit: 

• eine Repräsentation einer Ressource holen: HTTP GET 

• eine neue Ressource erstellen: HTTP PUT an einen neuen URI oder HTTP 

POST an eine bestehende (siehe den Abschnitt »POST« auf Seite 112) 

• eine bestehende Ressource verändern: HTTP PUT an einen bestehenden URI 

• eine bestehende Ressource löschen: HTTP DELETE 

Ich werde erläutern, wie diese vier Methoden verwendet werden, um jede Operation 

darzustellen, die Sie sich vorstellen können. Ich werde auch zwei HTTP-Methoden 

für weniger gebräuchliche Operationen vorstellen: HEAD und OPTIONS. 

GET, PUT und DELETE 

Diese drei sollten Ihnen noch vom S3-Beispiel in Kapitel 3 vertraut sein. Um eine 

Ressource zu holen oder zu löschen, schickt der Client einfach einen GET- oder 

DELETE-Request an den entsprechenden URI. Im Fall eines GET-Requests schickt 

der Server eine Repräsentation im Entity-Body der Response zurück. Bei einem 

DELETE-Request kann der Entity-Body eine Statusmitteilung oder auch gar nichts 

enthalten. 

Um eine Ressource zu erstellen oder zu verändern, schickt der Client einen PUT- 

Request, der normalerweise einen Entity-Body enthält. Dazu gehört die vom Client 

vorgeschlagene neue Repräsentation der Ressource. Welche Daten das sind und wie 

sie formatiert sind, hängt vom Service ab. Egal wie sie aussehen – dies ist die Stelle, 

an der der Anwendungszustand zum Server wandert und ein Ressourcen-Zustand 

wird. 

Schauen wir uns wieder den S3-Service an, in dem Sie zwei Arten von Ressourcen 

erstellen können: Buckets und Objekte. Um ein Objekt anzulegen, schicken Sie 

einen PUT-Request an seinen URI und übergeben den Inhalt des Objekts im Entity- 

Body Ihres Requests. Dasselbe machen Sie, um ein Objekt zu verändern: Der neue 

Inhalt überschreibt jeden vorhandenen alten. 

Das Erstellen eines Buckets läuft ein wenig anders ab, da Sie keinen Entity-Body im 

PUT-Request angeben müssen. Ein Bucket hat abgesehen von seinem Namen keinen 

Ressourcen-Zustand, und der Name ist Teil des URI. (Das ist nicht ganz korrekt. Die 

Objekte in einem Bucket sind auch Elemente des Ressourcen-Zustands dieses Buckets, 

denn sie werden aufgelistet, wenn Sie die Repräsentation eines Buckets per GET 

holen. Aber jedes S3-Objekt ist eine Ressource für sich, daher gibt es keinen Grund, 

ein Objekt über sein Bucket zu verändern. Jedes Objekt bietet die einheitliche 

Links 

Max. 

Linie 







Rechts 

Schnittstelle an, und sie können es separat anpassen.) Legen Sie denURI des Buckets 

fest, spezifizieren Sie damit auch seine Repräsentation. PUT-Requests enthalten für 

die meisten Ressourcen einen Entity-Body mit einer Repräsentation, aber wie Sie 

sehen, ist dies nicht zwingend erforderlich. 

HEAD und OPTIONS 

Es gibt drei andere HTTP-Methoden, die ich als Teil der einheitlichen Schnittstelle 

betrachte. Zwei davon sind einfache Hilfsmethoden, daher werde ich sie als Erstes 

behandeln. 

• nur die Repräsentation der Metadaten holen: HTTP HEAD 

• prüfen, welche HTTP-Methoden eine bestimmte Ressource unterstützt: HTTP 

OPTIONS 

Sie haben die Methode HEAD schon bei den S3-Service-Ressourcen in Kapitel 3 in 

Aktion gesehen. Ein S3-Client nutzt HEAD, um Metadaten zu einer Ressource zu 

holen, ohne den eventuell enorm großen Entity-Body laden zu müssen. Genau dafür 

ist HEAD gedacht. Ein Client kann HEAD verwenden, um zu prüfen, ob eine Ressource 

existiert, oder andere Informationen über sie erhalten, ohne ihre gesamte 

Repräsentation zu holen. HEAD gibt Ihnen genau das zurück, was auch GET liefern 

würde, aber ohne den Entity-Body. 

Es gibt zwei Standard-HTTP-Methoden, die ich in diesem Buch 

nicht behandeln werde: TRACE und CONNECT. TRACE wird 

genutzt, um Proxies zu debuggen, während man CONNECT verwendet, 

um ein anderes Protokoll über einen HTTP-Proxy weiterzuleiten. 

Max. 

Linie 

Die Methode OPTIONS ermöglicht dem Client herauszufinden, was man mit einer 

Ressource anstellen kann. Die Response auf einen OPTIONS-Request enthält den 

HTTP-Header Allow, der die Untermenge der einheitlichen Schnittstelle angibt, die 

von dieser Ressource unterstützt wird. Hier ein Beispiel-Header: 

Allow: GET, HEAD 

Aufgrund dieses Headers kann der Client davon ausgehen, dass der Server auf GEToder 

HEAD-Requests für diese Ressource sinnvoll reagiert, aber keine anderen 

HTTP-Methoden unterstützt werden. Diese Ressource ist also nur lesend ansprechbar. 

Die Header, die der Client im Request schickt, können eventuell den Header Allow 

verändern, den der Server als Reaktion zurückschickt. Wenn Sie zum Beispiel einen 

passenden Authorization-Header mit einem OPTIONS-Request senden, kann es 

sein, dass Sie GET-, HEAD-, PUT- und DELETE-Requests für einen bestimmten 

URI schicken dürfen. Senden Sie den gleichen OPTIONS-Request, lassen aber den 

Max. 

Linie 



| 111 





Header Authorization weg, ist Ihnen vielleicht nur GET und HEAD gestattet. Die 

Methode OPTIONS ermöglicht dem Client, einfache Zugriffskontrollprüfungen 

vorzunehmen. 

Theoretisch kann der Server zusätzliche Informationen als Response auf einen 

OPTIONS-Request schicken und der Client kann OPTIONS-Requests senden, die 

den Server zu spezifischen Möglichkeiten befragen. Schön und gut, nur leider kein 

akzeptierter Standard in Bezug auf das, was ein Client in einem OPTIONS-Request 

fragen darf. Neben dem Header Allow gibt es keine akzeptierten Standards, was ein 

Server als Response schicken könnte. Die meisten Web-Server und Frameworks 

unterstützen OPTIONS nur sehr eingeschränkt. Bisher ist OPTIONS nur eine vielversprechende 

Idee, die niemand verwendet. 

Links 

Max. 

Linie 

POST 

Nun kommen wir zur am meisten missverstandenen HTTP-Methode: POST. Diese 

Methode hat prinzipiell zwei Funktionen: eine, die innerhalb der Grenzen von REST 

liegt, und eine, die sich außerhalb befindet und ein Element im RPC-Stil einführt. In 

komplexen Fällen wie diesem ist es am besten, auf den Originaltext zurückzugreifen. 

Folgendes sagt RFC 2616, der HTTP-Standard, über POST (aus dem Abschnitt 9.5): 

POST wurde entworfen, um eine einheitliche Methode für folgende Funktionen zu 

bieten: 

• Kommentieren bestehender Ressourcen 

• Posten einer Nachricht an ein Bulletin Board, eine Newsgroup, eine Mailing-Liste 

oder ähnliche Artikelsammlungen 

• Bereitstellen von Daten wie zum Beispiel dem Ergebnis eines Formular-Submits an 

einen datenverarbeitenden Prozess 

• Erweitern einer Datenbank durch eine Append-Operation 

Die tatsächlich durch POST ausgeführte Funktion wird durch den Server bestimmt 

und hängt normalerweise von dem Request-URI ab. Die gepostete Entität ist diesem 

URI genauso untergeordnet, wie eine Datei einem Verzeichnis untergeordnet ist, in 

dem sie liegt, ein News-Artikel einer Newsgroup, in der er gepostet wurde, oder ein 

Datensatz einer Datenbank. 

Was bedeutet das im Kontext von REST und der ROA? 

Untergeordnete Ressourcen erstellen 

In einem REST-konformen Design wird POST häufig verwendet, um untergeordnete 

Ressourcen zu erzeugen, also solche, die in Beziehung zu anderen »Eltern«-Ressourcen 

stehen. Ein Weblog-Programm könnte zum Beispiel jedes Weblog als Ressource 

bereitstellen (/weblogs/myweblog) und die einzelnen Weblog-Einträge als untergeordnete 

Ressourcen (/weblogs/myweblog/entries/1). Eine Datenbank mit Web- 

Anschluss mag eine Tabelle als Ressource bereitstellen und die einzelnen Daten- 

Max. 

Linie 







Rechts 

Max. 

Linie 

bankzeilen als deren untergeordnete Ressourcen. Um einen Weblog-Eintrag oder 

eine Datenbankzeile zu erzeugen, schicken Sie ein POST an das Eltern-Element: das 

Weblog oder die Datenbanktabelle. Was für Daten Sie posten, und in welchem Format, 

hängt vom Service ab, aber wie bei PUT ist dies der Moment, in dem ein 

Anwendungszustand ein Ressourcen-Zustand wird. Sie können diese Verwendung 

von POST als POST(a) bezeichnen, für »Anhängen«. Wenn ich in diesem Buch 

»POST« schreibe, meine ich so gut wie immer POST(a). 

Warum können Sie nicht einfach PUT verwenden, um untergeordnete Ressourcen 

zu erstellen? Nun, manchmal können Sie das. Ein S3-Objekt ist eine untergeordnete 

Ressource, denn jedes S3-Objekt ist in einem S3-Bucket enthalten. Aber wir erstellen 

kein S3-Objekt, indem wir einen POST-Request an das Bucket schicken. Wir senden 

ein PUT direkt an den URI des Objekts. Der Unterschied zwischen PUT und POST 

ist dieser: Der Client nutzt PUT, wenn er dafür verantwortlich ist zu entscheiden, 

welchen URI die neue Ressource bekommen soll. Er nutzt POST, wenn der Server 

die Entscheidung über den URI der neuen Ressource fällen soll. 

Der S3-Service erwartet, dass Clients S3-Objekte mit PUT anlegen, da der URI eines 

S3-Objekts vollständig durch seinen Namen und den des Buckets festgelegt wird. 

Wenn der Client genug darüber weiß, wie das Objekt anzulegen ist, weiß er auch, 

wie der URI lauten wird. Der offensichtliche URI, der als Ziel des PUT-Requests verwendet 

wird, ist der, der das Bucket nutzen wird, sobald er existiert. 

Aber stellen Sie sich eine Anwendung vor, in der der Server mehr Kontrolle über die 

URIs hat, zum Beispiel ein Weblog-Programm. Der Client kann alle Informationen 

sammeln, die notwendig sind, um einen Weblog-Eintrag zu erstellen, und trotzdem 

nicht wissen, welchen URI der Eintrag haben wird, nachdem er einmal angelegt 

wurde. Vielleicht basieren die vom Server erstellten URIs auf der Reihenfolge einer 

internen Datenbank-ID: Wird der fertige URI /weblogs/myweblog/entries/1 oder 

/weblogs/myweblog/entries/1000 lauten? Vielleicht basiert der endgültige URI auf 

dem Zeitpunkt der Veröffentlichung: Von welcher Zeit geht der Server aus? Der 

Client sollte solche Dinge nicht wissen müssen. 

Die POST-Methode ist eine Möglichkeit, neue Ressourcen zu erstellen, ohne dass 

der Client den genauen URI wissen muss. In den meisten Fällen benötigt der Client 

nur den URI einer »Eltern«- oder »Fabrik«-Ressource. Der Server holt sich die 

Repräsentation aus dem Entity-Body und verwendet sie, um eine neue Ressource 

»unterhalb« der »Eltern«-Ressource anzulegen (die Bedeutung von »unterhalb« 

hängt vom Kontext ab). 

Die Response auf diese Art von POST-Requests hat normalerweise einen HTTP-Statuscode 

201 (»Created«). Sein Header Location enthält den URI der neu erstellten 

untergeordneten Ressource. Nachdem die Ressource nun tatsächlich existiert und 

der Client ihren URI kennt, können zukünftige Requests die PUT-Methode ver- 

Max. 

Linie 



| 113 





wenden, um diese Ressource zu verändern, mit GET eine Repräsentation davon 

holen und sie mit DELETE löschen. 

Tabelle 4-1 zeigt, wie ein PUT-Request an einen URI die zugrundeliegende Ressource 

erstellen oder verändern kann, und wie ein POST-Request an denselben URI eine 

neue, untergeordnete Ressource erzeugen kann. 

Links 

Tabelle 4-1: PUT-Aktionen 

/weblogs 

PUT an eine neue 

Ressource 

– (Ressource besteht 

bereits) 

PUT an eine bestehende 

Ressource 

Kein Effekt 

/weblogs/myweblog Erstelle dieses Weblog Verändere die Einstellungen 

dieses Weblogs 

/weblogs/myweblog/ 

entries/1 

– (wie würden Sie zu diesem 

URI kommen?) 

Diesen Weblog-Eintrag 

verändern 

POST 

Erstelle ein neues Weblog 

Erstelle einen neuen 

Weblog-Eintrag 

Einen Kommentar zu diesem 

Weblog-Eintrag 

posten 

Max. 

Linie 

An den Ressourcen-Zustand anhängen 

Die Informationen, die in einem POST an eine Ressource transportiert werden, müssen 

nicht zu einer komplett neuen, untergeordneten Ressource führen. Manchmal 

werden die Daten bei einem POST an eine Ressource an ihren eigenen Zustand angehängt, 

anstatt sie in eine neue Ressource zu stecken. 

Stellen Sie sich einen Ereignisprotokollservice vor, der eine einzige Ressource bereitstellt: 

das Log. Nehmen wir an, sein URI wäre /log. Um das Log zu holen, schicken 

Sie einen GET-Request an /log. 

Wie soll nun ein Client etwas an das Log anhängen? Er könnte einen PUT-Request 

an /log schicken, aber die PUT-Methode ist eigentlich dazu gedacht, eine neue Ressource 

zu erstellen oder alte Einstellungen durch neue zu überschreiben. Der Client 

will aber beides nicht, sondern nur Informationen an das Ende des Logs anhängen. 

Die POST-Methode passt hier, so als ob jeder Log-Eintrag als eigenständige Ressource 

bereitgestellt würde. Die Semantik von POST ist in beiden Fällen gleich: Der Client 

fügt einer bestehenden Ressource untergeordnete Informationen hinzu. Der einzige 

Unterschied liegt darin, dass beim Weblog und seinen Einträgen die untergeordneten 

Informationen als neue Ressourcen erscheinen. Hier taucht die untergeordnete 

Information als neues Datenelement in der Repräsentation des Eltern-Elements 

auf. 

Überladenes POST: Die nicht so einheitliche Schnittstelle 

Diese Art, die Sache zu betrachten, erklärt einen Großteil dessen, was der HTTP- 

Standard über POST sagt. Sie können es verwenden, um Ressourcen unterhalb einer 

Max. 

Linie 







Rechts 

Max. 

Linie 

Eltern-Ressource zu erstellen oder um zusätzliche Daten an den aktuellen Zustand 

einer Ressource anzuhängen. Die eine Verwendung von POST, die ich bisher nicht 

erklärt habe, ist die, mit der Sie vermutlich am besten vertraut sind, da damit so gut 

wie alle Web-Anwendungen arbeiten: das Liefern von Daten, wie zum Beispiel dem 

Ergebnis eines abgeschickten Formulars, an einen datenverarbeitenden Prozess. 

Was ist ein »datenverarbeitender Prozess«? Das kling ziemlich vage. Und tatsächlich 

kann so gut wie alles ein datenverarbeitender Prozess sein. Verwendet man POST auf 

diese Art und Weise, verwandelt man eine Ressource in einen kleinen Nachrichtenprozessor, 

der sich wie ein XML-RPC-Server verhält. Die Ressource akzeptiert einen 

POST-Request, begutachtet ihn und entscheidet sich dazu, irgendetwas zu tun. 

Dann entscheidet er sich dazu, dem Client irgendwelche Daten zu liefern. 

Ich bezeichne diese Verwendung von POST als überladenes POST, in Analogie zum 

Überladen von Operatoren in einer Programmiersprache. Es ist überladen, weil eine 

einzelne HTTP-Methode verwendet wird, um für viele Nicht-HTTP-Methoden zu 

stehen. Es ist aus dem gleichen Grund verwirrend, wie das Überladen von Operatoren 

verwirrend sein kann: Sie dachten, Sie wüssten, was HTTP-POST tut, aber nun 

wird es verwendet, um einem unbekannten Zweck zu dienen. Sie könnten das überladene 

POST als POST(p) bezeichnet finden – für »prozessiert«. 

Wenn Ihr Service überladenes POST bereitstellt, kommt wieder die Frage auf: 

»Warum sollte der Server dies tun statt jenes?« Jeder HTTP-Request muss Methodeninformationen 

enthalten, und wenn Sie überladenes POST verwenden, kann dies 

nicht in der HTTP-Methode geschehen. Die POST-Methode ist nur eine Direktive an 

den Server, die sagt: »Schau in den HTTP-Request, um die eigentliche Methoden- 

Information zu erhalten.« Die eigentliche Information kann in dem URI, den HTTP- 

Headern oder dem Entity-Body enthalten sein. Wie auch immer die Sache vor sich 

geht – ein bisschen RPC-Stil ist auf jeden Fall in den Service gesickert. 

Wenn sich die Methoden-Information nicht in der HTTP-Methode befindet, ist die 

Schnittstelle nicht mehr einheitlich. Die eigentliche Methoden-Information kann 

sonstwo sein. Als REST-Partisane mag ich das nicht wirklich, aber manchmal lässt es 

sich nicht vermeiden. Bis Kapitel 9 werden Sie gesehen haben, wie so gut wie jedes 

denkbare Szenario über die einheitliche Schnittstelle von HTTP zu verwirklichen ist, 

aber manchmal ist der RPC-Stil der einfachste Weg, um komplexe Operationen auszudrücken, 

die mehrere Ressourcen umfassen. 

Eventuell müssen Sie überladenes POST bereitstellen, auch wenn Sie POST nur 

nutzen, um untergeordnete Ressourcen anzulegen oder an eine Repräsentation einer 

Ressource anzuhängen. Was sollte man zum Beispiel tun, wenn eine einzelne Ressource 

beide Arten von POST unterstützt? Woher weiß der Server, ob ein Client ein 

POST abschickt, um eine untergeordnete Ressource zu erzeugen oder um an die 

bestehende Repräsentation der Ressourcen anzuhängen? Sie müssen vielleicht 

irgendwo im HTTP-Request zusätzliche Methoden-Informationen angeben. 

Max. 

Linie 



| 115 





Überladenes POST sollte nicht verwendet werden, um ein schlechtes Ressourcendesign 

zu verdecken. Denken Sie daran, dass eine Ressource so gut wie alles sein kann. 

Normalerweise ist es möglich, Ihr Ressourcendesign so zu verändern, dass die einheitliche 

Schnittstelle passt, anstatt den RPC-Stil in Ihren Service einzuführen. 

Links 

Max. 

Linie 

Sicherheit und Idempotenz 

Wenn Sie die uniforme Schnittstelle von HTTP so bereitstellen wollen, wie sie 

entworfen wurde, erhalten Sie zwei nützliche Eigenschaften kostenlos dazu. Verwendet 

man sie korrekt, sind GET- und HEAD-Requests sicher. Requests mit GET, 

HEAD, PUT und DELETE sind zudem idempotent. 

Sicherheit 

Ein GET- oder HEAD-Request ist eine Anfrage, um bestimmte Daten zu lesen, keine 

Anfrage, irgendwelche Serverzustände zu ändern. Der Client kann einen GET- oder 

HEAD-Request zehn Mal hintereinander ausführen und es wäre so, als ob er nur einmal 

oder niemals gesendet worden wäre. Wenn Sie per GET http://www.google.com/ 

search?q=Quallen anfordern, ändern Sie nichts im Verzeichnis der Ressourcen über 

Quallen. Sie holen einfach nur eine Repräsentation davon ab. Ein Client sollte in der 

Lage sein, einen GET- oder HEAD-Request an einen unbekannten URI zu schicken, 

ohne sich Sorgen machen zu müssen, ob etwas zerstört wird. 

Das heißt nicht, dass GET- und HEAD-Requests keine Nebeneffekte haben können. 

Manche Ressourcen führen Zähler, die bei jedem Zugriff eines Clients per GET 

erhöht werden. Die meisten Web-Server protokollieren jeden eingehenden Request 

in einer Log-Datei. Das sind Nebeneffekte: Der Server-Zustand und sogar der Ressourcen-Zustand 

werden als Reaktion auf einen GET-Request geändert. Aber der 

Client hat nicht darum gebeten und ist dafür auch nicht verantwortlich. Ein Client 

sollte niemals einen GET- oder HEAD-Request nur aufgrund der Nebeneffekte ausführen, 

und die Nebeneffekte sollten auch niemals so stark sein, dass der Client sich 

wünschte, er hätte den Request niemals abgeschickt. 

Idempotenz 

Idempotenz ist etwas trickreicher. Die Idee kommt aus der Mathematik, und wenn 

Sie mit Idempotenz nicht vertraut sind, kann ein mathematisches Beispiel vielleicht 

helfen. Eine idempotente Operation in der Mathematik ist eine, die bei einmaliger 

Anwendung denselben Effekt hat wie bei mehrfacher. Das Multiplizieren einer Zahl 

mit Null ist idempotent: 4 × 0 × 0 × 0 ist das Gleiche wie 4 × 0. 6 Analog dazu ist eine 

Operation auf einer Ressource idempotent, wenn das Abschicken eines Requests das 

6 Das Multiplizieren einer Zahl mit 1 ist sowohl sicher als auch idempotent: 4 × 1 × 1 × 1 ist das Gleiche 

wie 4 ×1, ergibt nämlich 4. Die Multiplikation mit Null ist nicht sicher, da 4 × 0 nicht das Gleiche wie 

4 ist. Das Multiplizieren mit jeder anderen Zahl ist weder sicher noch idempotent. 

Max. 

Linie 







Rechts 

Max. 

Linie 

Gleiche ist wie das Abschicken einer ganzen Serie identischer Requests. Der zweite 

und folgende Requests belassen den Ressourcen-Zustand in exakt dem gleichen 

Zustand wie er durch den ersten Request entstanden ist. 

PUT- und DELETE-Operationen sind idempotent. Wenn Sie eine Ressource per 

DELETE löschen, ist sie weg. Wenn Sie DELETE erneut abfeuern, bleibt sie verschwunden. 

Wenn Sie eine neue Ressource mit PUT anlegen und dann PUT nochmals 

abschicken, ist die Ressource immer noch da und hat auch die gleichen 

Eigenschaften wie nach dem ersten PUT. Wenn Sie PUT verwenden, um den 

Zustand einer Ressource zu ändern, können Sie den PUT-Request nochmals senden, 

ohne dass sich der Ressourcen-Zustand ändern wird. 

Ein zu beachtender Punkt ist daher, dass Sie Ihren Clients nicht erlauben sollten, 

Repräsentationen per PUT zu übermitteln, die einen Ressourcenstatus mit relativen 

Werten ändern. Wenn eine Ressource einen numerischen Wert als Teil ihres 

Zustands enthält, kann ein Client vielleicht PUT nutzen, um den Wert auf 4 oder 0 

oder -50 zu setzen, aber nicht, um den Wert um 1 zu erhöhen. Wenn der ursprüngliche 

Wert 0 ist und man zwei PUT-Requests schickt, die sagen: »Setze den Wert auf 

4«, bleibt der Wert auf 4. Wenn der Anfangswert 0 ist und man zwei PUT-Requests 

schickt, die sagen »Erhöhe den Wert um 1«, wird der Wert danach nicht 1, sondern 

2 sein. Das ist nicht idempotent. 

Warum Sicherheit und Idempotenz wichtig sind 

Sicherheit und Idempotenz ermöglichen einem Client, zuverlässige HTTP-Requests 

über ein unzuverlässiges Netzwerk zu versenden. Wenn Sie einen GET-Request 

abschicken und keine Response erhalten, feuern Sie ihn einfach nochmals ab. Er ist 

sicher: Selbst wenn Ihr erster Request angekommen war, hatte er keinen echten 

Effekt auf den Server. Wenn Sie einen PUT-Request machen und keine Response 

erhalten, schicken Sie ihn nochmals los. Wenn Ihr erster Request durchgekommen 

ist, wird ein zweiter keinen zusätzlichen Effekt haben. 

POST ist weder sicher noch idempotent. Das Abschicken zweier identischer POST- 

Requests an eine »Fabrik«-Ressource wird vermutlich in zwei untergeordneten Ressourcen 

enden, die beide die gleichen Informationen enthalten. Bei überladenem 

POST kann man gar nicht mehr sagen, was passieren wird. 

Der häufigste Missbrauch der einheitlichen Schnittstelle ist, unsichere Operationen 

per GET verfügbar zu machen. Sowohl del.icio.us als auch die Flickr-API tun dies. 

Wenn Sie per GET https://api.del.icio.us/posts/delete aufrufen, erhalten Sie keine 

Repräsentation – stattdessen verändern Sie den Datensatz bei del.icio.us. 

Warum ist das schlecht? Nun, dazu eine kleine Geschichte. Im Jahr 2005 veröffentlichte 

Google ein Caching-Tool für den Client namens Web Accelerator. Es lief 

zusammen mit dem Web-Browser und holte die Seiten im Voraus, die auf der aktuell 

betrachteten Seite einen Verweis hatten. Wenn man dann auf einen dieser Verweise 

Max. 

Linie 



| 117 





Max. 

Linie 

klickte, wurde die entsprechende Seite schneller geladen, da der Computer sie schon 

empfangen hatte. 

Der Web Accelerator war ein Desaster. Nicht aufgrund eines Problems in der Software 

selbst, sondern weil das Web voll von Anwendungen ist, die GET missbrauchen. 

Der Web Accelerator nahm an, dass GET-Operationen sicher wären und 

Clients sie schon im Voraus laden konnten, falls jemand die entsprechende 

Repräsentation sehen wollte. Aber wenn diese GET-Anfragen an reale URIs 

geschickt wurden, änderten sich Datensätze. Die Leute verloren Daten. 

Man kann die Schuld hier großzügig verteilen: Programmierer sollten keine 

unsicheren Aktionen per GET ansprechbar machen, und Google hätte kein Tool für 

die reale Welt veröffentlichen sollen, das im realen WWW nicht funktioniert. Die 

aktuelle Version des Web Accelerator ignoriert alle URIs, die Query-Variablen 

enthalten. Das löst einen Teil des Problems, verhindert aber auch, dass viele Ressourcen, 

die man per GET sicher laden könnte (wie zum Beispiel die Web-Suchen von 

Google), im Voraus geladen werden. 

Sie können noch viele Beispiele bekommen. Viele Web Services und Web-Anwendungen 

verwenden URIs als Eingabeparameter, und als Erstes schicken sie einen 

GET-Request, um eine Repräsentation einer Ressource zu erhalten. Diese Services 

wollen keine katastrophalen Nebeneffekte auslösen, aber sie haben es nicht in der 

Hand. Es ist Aufgabe des Service, einen GET-Request so zu handhaben, dass er mit 

dem HTTP-Standard konform ist. 

Warum die einheitliche Schnittstelle wichtig ist 

Wichtig an REST ist nicht, dass Sie die spezielle einheitliche Schnittstelle verwenden, 

die HTTP definiert. REST spezifiziert eine einheitliche Schnittstelle, sagt aber nicht, 

welche einheitliche Schnittstelle. GET, PUT und der Rest sind nicht für alle Zeiten 

die perfekte Schnittstelle. Wichtig ist die Einheitlichkeit: Jeder Service verwendet die 

HTTP-Schnittstelle auf die gleiche Art und Weise. 

Der Punkt ist nicht, dass GET der beste Name für eine lesende Operation ist, 

sondern dass GET im ganzen Web »Lesen« bedeutet – egal, welche Ressource Sie 

dabei ansprechen. Bei einem gegebenen URI einer Ressource ist es keine Frage, wie 

Sie eine Repräsentation erhalten: Sie schicken einen HTTP-GET-Request an diesen 

URI. Die einheitliche Schnittstelle lässt zwei Services sich so ähnlich werden wie zwei 

Web-Sites. Ohne diese Einheitlichkeit müssen Sie lernen, wie jeder Service Informationen 

erwartet und verschickt. Die Regeln könnten sich sogar von Ressource zu 

Ressource innerhalb eines Service unterscheiden. 

Sie können einem Computer beibringen zu verstehen, was GET bedeutet – dann gilt 

dieses Verständnis für jeden REST-konformen Web Service. Da gibt es auch nicht 

viel zu verstehen. Der für den Service spezifische Code kann sich dann um die Behand- 

Links 

Max. 

Linie 







Rechts 

Max. 

Linie 

lung der Repräsentation kümmern. Ohne die einheitliche Schnittstelle erhalten Sie 

eine viel größere Anzahl an Methoden, die den Platz von GET einnehmen: doSearch 

und getPage und nextPrime. Jeder Service spricht eine andere Sprache. Das ist auch 

der Grund, warum ich überladenes POST nicht so sehr mag: Es verwandelt das einfache 

Esperanto der einheitlichen Schnittstelle in ein babylonisches Gewirr einmalig 

genutzter Untersprachen. 

Manche Anwendungen erweitern die einheitliche Schnittstelle von HTTP. Der offensichtlichste 

Fall ist da WebDAV, das acht neue HTTP-Methoden hinzufügt, unter 

anderem MOVE, COPY und SEARCH. Die Verwendung dieser Methoden in einem 

Web Service würde keine Regel von REST verletzen, da REST nicht aussagt, wie die 

einheitliche Schnittstelle aussehen soll. Die Nutzung dieser Methoden würde allerdings 

nicht in meine ressourcenorientierte Architektur passen (da ich die ROA 

explizit mit den Standard-HTTP-Methoden verbunden habe), wobei so ein Service 

trotzdem noch allgemein gesprochen ressourcenorientiert sein könnte. 

Der eigentliche Grund, warum man keine WebDAV-Methoden nutzen sollte, ist, 

dass Sie damit Ihren Service inkompatibel zu anderen REST-konformen Services 

machen. Ihr Service würde eine andere einheitliche Schnittstelle verwenden als die 

meisten anderen. Es gibt Web Services wie Subversion, die die WebDAV-Methoden 

nutzen, daher wäre Ihr Service nicht allein. Aber er wäre nur ein Teil eines weitaus 

kleineren Webs. Das ist der Grund dafür, dass das Entwickeln eigener HTTP-Methoden 

eine sehr, sehr schlechte Idee ist: Ihr eigenes Vokabular lässt die Community 

deutlich schrumpfen. Da können Sie auch gleich XML-RPC nutzen. 

Eine andere einheitliche Schnittstelle besteht einzig und allein aus HTTP GET und 

überladenem POST. Um eine Repräsentation einer Ressource zu erhalten, schicken 

Sie ein GET an ihren URI. Um eine Ressource zu erstellen, zu verändern oder zu 

löschen, schicken Sie ein POST. Diese Schnittstelle ist vollständig REST-konform, 

aber passt auch nicht zu meiner ressourcenorientierten Architektur. Diese Schnittstelle 

ist gerade ausreichend, um zwischen sicheren und unsicheren Operationen zu 

unterscheiden. Eine ressourcenorientierte Web-Anwendung würde diese Schnittstelle 

nutzen, weil heutige HTML-Formulare nur GET und POST unterstützen. 

Das war’s! 

Das ist die ressourcenorientierte Architektur. Es gibt nur vier Konzepte: 

1. Ressourcen 

2. ihre Namen (URIs) 

3. ihre Repräsentationen 

4. die Verweise zwischen ihnen 

Max. 

Linie 

Das war’s! | 119 






Und es gibt vier Eigenschaften: 

1. Adressierbarkeit 

2. Zustandslosigkeit 

3. Verbindungshaftigkeit 

4. eine einheitliche Schnittstelle 

Natürlich bleibt eine Reihe Fragen offen. Wie sollten reale Daten in Ressourcen aufgeteilt 

und wie sollten diese Ressourcen organisiert werden? Was sollte dann in den 

HTTP-Requests und -Responses stehen? Ich werde einen Großteil der verbleibenden 

Seiten dazu nutzen, solche Fragen anzusprechen. 

Links 

Max. 

Linie 

Max. 

Linie

Die ressourcenorientierte Architektur - beim O'Reilly Verlag

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?