Der Begriff REST wurde geprägt durch Roy Fielding (u.a. Chairman der Apache Software Foundation) in seiner Dissertation Architectural Styles and the Design of Network-based Software Architectures [1] aus dem Jahre 2000. REST steht für Representational State Transfer - und dieser Begriff (Kapitel 5 der Dissertation) steht für die Architektur eines verteilten Hypermedia-Systems (wovon das heutige Web nur eine Ausprägung ist). REST hat ursprünglich also nichts mit Web Services zu tun.
Bei dem Begriff Representation handelt es sich um die Darstellung der Ressource, die man über das Netzwerk erhält - z.B. bei einem GET. Eine Ressource kann verschiedene Darstellungen haben, je nachdem, was die Client-Applikation verarbeiten kann. Da der Client bei jeder Übertragung eine bestimmte Darstellung erhält, wird er dadurch in einen neuen Zustand versetzt. Dies wird auch durch die Verlinkung der verschiedenen Darstellungen untereinander unterstützt wie wir noch sehen werden.
Als Roy Fielding und andere um 1993 begannen, die verschiedenen Technologien des Webs zu definieren und zu entwickeln, spielten bestimmte Prinzipien eine Rolle. Prinzipien, die wir heute alle kennen und schätzen. In seiner Dissertation definiert Roy Fielding die Eigenschaften eines REST-Systems (hier im Auszug) wie folgt:

• Ein REST-Netzwerk besteht aus Client und Server.v
• Jeder Request, der vom Client zum Server geschickt wird, muss alle notwendigen Informationen für die Durchführung auf dem Server beinhalten. Der Client darf keine Annahmen über den Serverstatus machen.
• Responses vom Server müssen in der Lage sein, als cacheable oder non-cacheable markiert zu werden.
• Alle Ressourcen müssen über eine fest definierte Schnittstelle zugänglich sein.
• Ein REST-System besteht aus Ressourcen, die per URI adressiert werden.
• Weder Client noch Server müssen die Bedeutung einer URI verstehen. Die gleiche Darstellung kann auch durch verschiedene URIs erreicht werden.
• Darstellungen werden untereinander verlinkt, um dem Client die Möglichkeit zu geben, von einem Zustand in den nächsten zu wechseln.

Um es gleich vorwegzuschicken: das heutige Web hält sich nicht durchgängig an die vorgegebenen REST-Prinzipien - so verletzt z.B. das Verwenden von Cookies bereits den zweiten Punkt der obigen Liste, da das Speichern eines Sessionkontexts auf dem Server in REST nicht vorgesehen ist.
Anhand eines einfachen Beispiels - der Abfrage eines Kontostands - sollen die wichtigsten REST-Prinzipien erläutert werden. Wünscht der Kunde Zugriff auf seine Kontoinformationen, so reicht es zuerst aus, die folgende URI aufzurufen:

1. GET http://meinebank.de/engagement/1234450

Hierbei ist 1234450 die Hauptkontonummer. Als Ergebnis eines solchen GETs wird ein Objekt (z.B. eine XML-Darstellung des Hauptkontos) zurückgeliefert. Vereinfacht dargestellt:

1. <konto>
2. <inhaber>Matthew Langham</inhaber>
3. <unterkonten>
4. <unterkonto xlink:href="
5. http://meinebank.de/engagement/1234450/30">Giro</unterkonto>
6. <unterkonto xlink:href="http://meinebank.de/engagement/1234450/40">Spar</unterkonto>
7. </unterkonten>
8. </konto>

Durch die Verwendung von Links (in einer XML-Darstellung z.B. über xlink) innerhalb der zurückgelieferten Darstellung erhält die Clientapplikation die Möglichkeit, eine Zuordnung zwischen einer Benutzerauswahl in einer Maske und der nächsten URI herzustellen. Wählt der Benutzer als nächstes das Girokonto, so werden diese Informationen durch den Aufruf der folgenden URI geliefert:

1. GET http://meinebank.de/engagement/1234450/30

Das Ergebnis des Aufrufs ist die aktuelle Darstellung des spezifischen Kontos - vielleicht mit weiteren Links ergänzt, um z.B. die Kontobewegungen abzurufen:

1. <kontoinfo typ="giro">
2. <saldo>4000 H</saldo>
3. <funktion xlink:href="
4. http://meinebank.de/engagement/1234450/30/bewegungen">Bewegungen</funktion>
5. </kontoinfo>

So navigiert der Client anhand der enthaltenen Links durch die möglichen Zustände. Neben der Verwendung von GET, um Darstellungen von Ressourcen zu bekommen (dies dürfte für jeden Websurfer offensichtlich sein), empfiehlt REST auch die Manipulation von Ressourcen durch Änderung der erhaltenen Darstellung und das Zurückschicken über die bereits definierte Schnittselle. Im Web könnte dies z.B. durch die Verwendung der HTTP-Verben POST, PUT und DELETE erreicht werden. Heutige REST-Verfechter weisen darauf hin, dass diese Verben ausreichen, um den kompletten Funktionsumfang eines Web Services bereitzustellen (obwohl Roy Fielding in seiner Dissertation die explizite Erwähnung der Verben POST und DELETE vermeidet und PUT nur am Rande erwähnt).
Wie einfach zu erkennen sein sollte, ist REST an und für sich keine neue Technologie. Die oben beschriebenen Eigenschaften haben das heutige Web geprägt und sind allgegenwärtig.

REST und Web Services

Warum hat REST auch in der Web Services-Welt für Aufregung gesorgt? Betrachtet man die heutigen SOAP Web Services, so stellt man eine starke Ähnlichkeit zu Konstrukten aus der Programmierwelt fest. Es ist sehr einfach, eine vorhandene Java-Klasse, z.B. mittels Apache Axis, als Web Service zur Verfügung zu stellen. Hierbei werden die einzelnen Funktionen der Schnittstelle als Web Service-Funktionen exportiert. Der Aufruf der einzelnen Funktionen erfolgt dann über den Austausch von SOAP-Nachrichten. Derzeit wird SOAP als Protokoll für die Implementierung von Web Services favorisiert, doch - so bringen SOAP-Kritiker an - hat dieses Protokoll einige Nachteile, wenn es darum geht, Web Services-Infrastrukturen zu etablieren:

• SOAP bietet keine Unterstützung für vorhandene HTTP Cache-Server (z.B. Squid). Da SOAP-Nachrichten mittels POST geschickt werden, werden sie (und die Antworten) nicht gecacht.
• Die Web Service-Schnittstelle ist je nach Service unterschiedlich. Zudem sind die eigentlichen Funktionen innerhalb der SOAP-Nachricht kodiert und von außen nicht zu erkennen.
• SOAP-Nachrichten werden von vorhandenen Webserver-Logs nicht erfasst. Es müssen neue Logging-Mechanismen implementiert werden.
• SOAP-Nachrichten umgehen vorhandene HTTP-Authentisierungsmechanismen. Es müssen neue Authentisierungsverfahren implementiert werden.
• SOAP-Nachrichten sind komplex und erfordern viel Implementierungsaufwand. Die einfache Abfrage z.B. eines Kontostands erfordert viel Overhead.

Die REST-Berfürworter argumentieren, dass sich diese Nachteile durch den Einsatz einer REST-Architektur korrigieren lassen. Durch die Verwendung von URIs, wie sie auch bei normalen Webseiten verwendet werden, können die vorhandenen Sicherheits- und Loggingverfahren eines Webservers eingesetzt werden. Zudem unterstützt REST eine lose Kopplung zwischen Client und Server durch die Verwendung von URIs. SOAP dagegen fördert eine stärkere Bindung zwischen Client und Server. Erzeugt man einen Client aus der WSDL-Beschreibung eines Servers, so ist es notwendig, diesen Client neu zu erzeugen, wenn sich an der Servicebeschreibung etwas ändert. Dies ist bei REST nicht zwingend notwendig, da sich der Aufruf einer Ressource nicht ändern muss, nur weil sich die Darstellung der Ressource ändert.

Cocoon - eine REST-Plattform?

Als Beispiel für die Implementierung einer (teilweise) REST-artigen Architektur kann man das Apache Open Source-Projekt Cocoon [2] betrachten. Dort werden alle Ressourcen, die eine auf Cocoon basierende Anwendung bereitstellt, mittels URI angeboten.
So ruft man z.B. die Einstiegsseite über die URI http://www.myserver.com/cocoon/welcome auf. Wie zu erkennen ist, adressiert der Nutzer eine Ressource auf dem Server. Was er letztendlich zurückbekommt, entscheidet allein der Server. Die Darstellung dieser Ressource wird auch erst zur Laufzeit generiert und kann unterschiedliche Formen annehmen. Ruft der Nutzer diese Ressource mit einem Browser auf, so kann Cocoon HTML zurückliefern. Cocoon kann aber auch WML zurückliefern, falls der Nutzer ein Handy einsetzt. Hierbei ändert sich nicht der Aufruf, sondern nur die Darstellung. Natürlich ist dies nur ein Aspekt eines REST-Systems und Cocoon ist nicht durchgängig auf REST ausgelegt.

Nachteile von REST

Der Einsatz einer REST-Architektur scheint viele Vorteile zu haben - doch hat auch diese Medaille eine zweite Seite. REST-Architekturen müssen immer noch implementiert werden:

• Die verschiedenen URIs müssen oft dynamisch generiert werden. Dies erfordert einen erhöhten Aufwand auf dem Server.
• Die Austauschformate zwischen Client und Server müssen in einer standardisierten Art und Weise dokumentiert werden.
• Obwohl die HTTP-Verben GET und POST überall implementiert sind, findet man kaum Unterstützung für die Verben PUT und DELETE. Diese Unterstützung müsste also nachträglich ergänzt werden. Dabei muss auf eine ausreichende Skalierbarkeit geachtet werden.
• Es ist aufwändig, atomare Transaktionen in REST zu implementieren. Für Transaktionen, z.B. im Online-Banking, ist es einfacher, eine Überweisung als SOAP-Aufruf zu implementieren (wobei alle notwendigen Daten innerhalb der SOAP-Nachricht kodiert werden), als einen solchen Vorgang über URIs abzuhandeln.

Discovery und Servicedefinition

Die heutigen Web Services-Standards umfassen weit mehr als nur SOAP. Installiert man ein Web Service, so muss der Client anschließend in die Lage versetzt werden, diesen Web Service zu entdecken, um ihn anschließend nutzen zu können. Hier existieren z.B. die Standards WSIL (Web Services Inspection Language) oder UDDI (Universal Description, Discovery and Integration). Auch REST-Architekturen müssen eine entsprechende Möglichkeit bieten.
Für die Definition von vorhandenen Services hat sich WSDL (Web Services Description Language) etabliert. Teilweise existieren Tools, um dieses Format zu erzeugen (z.B. aus einer Java-Klasse mit Axis). Auch REST Web Services müssen Informationen über die erwarteten und gelieferten Formate bereitstellen und daher ein Format wie WSDL einsetzen.

Amazon - SOAP und REST

Es existieren bereits einige Web Services in einer REST-artigen Form. Seit einigen Wochen bietet Amazon.com eine Web Services-Schnittstelle an [3]. Die Diskussion um REST und SOAP umgeht Amazon geschickt, indem beide Varianten unterstützt werden. Da Amazon nur Lesezugriffe bereitstellt (Suchen), ist die Implementierung eines Clients denkbar einfach. Um nach einem Buch zu Cocoon zu suchen, erzeugt man einen REST-Aufruf wie folgt:

1. GET http://xml.amazon.com/onca/xml?v=1.0&t=webservices-20&dev-t=Developer-Token&KeywordSearch=cocoon%20langham&mode=books&type=lite&f=xml

Man benötigt vorher einen so genannten Developer's Token, den man bei Amazon beantragen muss. Den (fast) gleichen Aufruf in SOAP sehen Sie in Listing 1.

Listing 1

1. <?xml version="1.0" encoding="UTF-8" ?>
2. <SOAP-ENV:Envelope xmlns:SOAP ENV="http://schemas.xmlsoap.org/soap/envelope/"
3. xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
4. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
5. xmlns:xsd="http://www.w3.org/2001/XMLSchema"
6. SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
8. <SOAP-ENV:Body>
9. <namesp1:KeywordSearchRequest xmlns:namesp1="urn:PI/DevCentral/SoapService">
10. <KeywordSearchRequest xsi:type="namesp1:KeywordRequest">
11. <keyword xsi:type="xsd:string">cocoon</keyword>
12. <page xsi:type="xsd:string">1</page>
13. <mode xsi:type="xsd:string">books</mode>
14. <tag xsi:type="xsd:string">webservices-20</tag>
15. <type xsi:type="xsd:string">lite</type>
16. <dev-tag xsi:type="xsd:string">Developer-Token</dev-tag>
17. <format xsi:type="xsd:string">xml</format>
18. <version xsi:type="xsd:string">1.0</version>
19. </KeywordSearchRequest>
20. </namesp1:KeywordSearchRequest>
21. </SOAP-ENV:Body>
22. </SOAP-ENV:Envelope>

Interessant ist die Tatsache, dass der SOAP-Aufruf es derzeit nicht erlaubt, mehrere Keywörter als Suchbegriffe anzugeben. Als Ergebnis beider Aufrufe erhält man dann eine Darstellung des Suchergebnisses in XML (siehe Listing 2).

Listing 2

1. <?xml version="1.0" encoding="UTF-8"?>
2. <!DOCTYPE ProductInfo PUBLIC "-//Amazon.com //DTD Amazon Product Info//EN" "http://xml.amazon.com/schemas/dev-lite.dtd">
3. <ProductInfo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xml.amazon.com/schemas/dev-lite.xsd">
4. <Details url="http://www.amazon.com/exec/obidos/redirect?tag=webservices-20%26creative=Developer-Token%26camp=2025%26link_code=xm2%26path=ASIN/0735712352">
5. <Asin>0735712352</Asin>
6. <ProductName>Cocoon: Building XML Applications</ProductName>
7. <Catalog>Book</Catalog>
8. <Authors>
9. <Author>Carsten Ziegeler</Author>
10. <Author>Matthew Langham</Author>
11. </Authors>
12. <ReleaseDate>19 July, 2002</ReleaseDate>
13. <Manufacturer>New Riders Publishing</Manufacturer>
14. <ImageUrlSmall>http://images.amazon.com/images/P/0735712352.01.THUMBZZZ.jpg</ImageUrlSmall>
15. <ImageUrlMedium>http://images.amazon.com/images/P/0735712352.01.MZZZZZZZ.jpg</ImageUrlMedium>
16. <ImageUrlLarge>http://images.amazon.com/images/P/0735712352.01.LZZZZZZZ.jpg</ImageUrlLarge>
17. <ListPrice>$39.99</ListPrice>
18. <OurPrice>$27.99</OurPrice>
19. </Details>
20. </ProductInfo>

Die Bereitstellung der Schnittstelle sowohl in einer REST- als auch einer SOAP-Form ist sicherlich ein kluger Schachzug von Amazon. Damit werden beide Lager befriedigt und die Nutzung des Web Services erleichtert.
Als Gegenbeispiel hierzu wird Google angesehen. Google hatte bis zur Freigabe einer öffentlichen Web Services-Schnittstelle ebenfalls eine Möglichkeit, über eine URI eine Suche abzusetzen. Diese Möglichkeit existiert jetzt allerdings nur noch gegen Bezahlung. Nur die SOAP-Variante ist kostenlos nutzbar (eine Tatsache, die zu einigem Wirbel in der Web Services-Gemeinde geführt hat [4]).

Der ganze REST

REST ist kein neuer Weg, Web Services zu bauen, es ist lediglich ein Architekturstil. Roy Fielding sagt explizit nicht, dass Zugriffe nur über GET abgewickelt werden sollen, sehr wohl aber, dass URIs für alle wichtigen Ressourcen eingesetzt werden sollten [5]. Die REST-Prinzipien, die er in seiner Dissertation darlegt, haben das Web zu dem gemacht, was es heute ist. Nun besteht aber das heutige Web zum überwiegenden Teil aus Lesezugriffen (z.B. einer Webseite). Die vorhandenen Systeme unterstützen insbesondere diesen Vorgang sehr gut und lassen dadurch eine hohe Skalierbarkeit zu. Für Schreibzugriffe bzw. das Verändern von Ressourcen auf einem Server sieht es dagegen anders aus. Hier werden andere Mittel eingesetzt, wie ftp oder xcopy. Eine Unterstützung für PUT und DELETE findet man dagegen kaum. Wie Sam Ruby (u.a. IBM Web Services-Vordenker) in [6] aufführt, hängt der Wert eines solchen Systems zum überwiegenden Teil davon ab, wie genau die Strukturen in Request und Response definiert und beschrieben sind. Dies trifft auch für ein REST-System zu.
In dem OSCON [7]-Vortrag des REST-Verfechters Paul Prescod [8] und in einem anschließenden Gespräch mit Sam Ruby wurde deutlich, dass die Lösung des Konflikts in einer Kombination beider Ansätze liegen wird. Durch die Verbindung von REST und SOAP können Web Services-Architekturen gebaut werden, die sowohl die Flexibilität und Skalierbarkeit des Webs nutzen als auch die Unterstützung von Web Services-Technologien wie SOAP und WSDL ermöglichen. Ein erster Schritt in diese Richtung sind die Aufnahme des Web Method Specification Features in SOAP 1.2 [9] und die Beschreibung der Verwendung von GET wenn es sich um Requests handelt, die durch ihre Ausführung keine Veränderung oder Seiteneffekte auslösen und bei denen ein Caching-Verhalten nicht stört. Damit lassen sich dann auch SOAP-Requests formulieren, die sich nicht von einem REST-Request unterscheiden.
Matthew Langham (mlangham@s-und-n.de) leitet das Open Source Competence Center der S&N AG in Paderborn. Er hat zu zahlreichen Themen des Webs Artikel veröffentlicht und ist Ko-Autor des Buches Cocoon: Building XML Applications (New Riders). Auf der diesjährigen OSCON hielt er eine Präsentation zum Cocoon XML Portal und hat sich dort auf die Suche nach dem ganzen REST begeben.

Links und Literatur

• [1] Roy Fieldings Dissertation: www.ebuilt.com/fielding/pubs/dissertation/top.htm
• [2] Apache Cocoon: xml.apache.org/cocoon/
• [3] Amazon Web Services (Partner-ID notwendig): www.amazon.com/webservices/
• [4] Paul Prescod, Googles Gaffe: www.xml.com/pub/a/2002/04/24/google.html
• [5] Roy Fielding, When to use GET: www.w3.org/2002/04/22-tag-summary#When
• [6] Sam Ruby über REST und SOAP:- radio.weblogs.com/0101679/stories/2002/07/20/restSoap.html
• [7] O'Reilly Open Source Convention: www.oreillynet.com/oscon2002/
• [8] Paul Prescod: www.prescod.net/rest/
• [9] SOAP 1.2: www.w3.org/TR/soap12/