Jusletter IT

Mit dem Aufkommen des Web 2.0 wurden aus ursprünglich unidirektionalen Interaktionen (Read) bidirektionale: Read, Create, Update und Delete. Aus technischer Sicht waren dafür neue Schnittstellen notwendig. Der Erfolg von Social Web Services wie Facebook, Flickr, Twitter oder YouTube (vgl. Leitner & Grechenig 2009) oder des Internethandels (E-Commerce) (Sackmann & Strüker 2005) mit Flagschiffen wie Amazon oder eBay basiert nicht zuletzt auf maßgeschneiderten Schnittstellen für die manuelle und automatisierte Interaktion mit Anwendungen im Web. Eine hierfür geeignete Schnittstellentechnik ist REST (Representational State Transfer). In vielen Lehrbüchern der Wirtschaftsinformatik (z.B. Mandl 2009; Abts & Mülder 2010) sucht man noch vergeblich nach dem Stichwort REST, in praxisorientierten Zeitschriften wird mitunter zu unkritisch reflektiert, aber auch in wissenschaftlichen Papers werden fallweise Begriffe vermischt. So bezeichnen Higashino et al (2009) im Kontext von REST die Begriffe URI, HTTP und XML allesamt als «Web protocols». Im Zusammenhang mit REST wird zudem oft von einem «Architekturstil» gesprochen (Fielding & Taylor 2002). Ein möglicher Kritikpunkt ist nun jener, dass es sich bei REST eher um eine sehr gut durchdachte Schnittstellenspezifikation handelt – allenfalls um eine Web 2.0 bzw. Web-orientierte Architektur (Dunkel et al. 2008) – denn um einen weitreichenden Architekturansatz für Integrationsaufgaben. Vielfach wird REST auch in direktem Zusammenhang mit einer serviceorientierten Architektur (SOA) gebracht (vgl. Heutschi 2007; Flieder 2009). Das ist grundsätzlich zwar nicht falsch, doch REST ist zum SOAP-basierten Web-Service-Interaktionsmodell funktional und konzeptionell nicht kompatibel, u.a. deshalb, da es lediglich mit HTTP (Hypertext Transfer Protocol) funktioniert. Umgekehrt unterstützt SOAP in der Version 1.2 mittlerweile REST-Funktionalität. Diese Abgrenzung ist wichtig, denn bei serviceorientierten Architekturen werden i.d.R. komplexe Services auf der Basis von Request-/ Reply-Nachrichten implementiert. Dies ist mit REST nicht möglich, es werden auch keine verteilten Transaktionen unterstützt, eine der Kernanforderungen im Distributed Computing. In den folgenden Abschnitten wird auf weitere Unterschiede zwischen diesen beiden Schnittstellentechniken eingegangen.

Die Grundzüge von REST wurden erstmals von Fielding (2000) im Zuge einer Dissertation formuliert. Während das «klassische», SOAP-basierte Web-Service-Interaktionsmodell das Internet hauptsächlich als Medium für die Interaktion und die Kommunikation zwischen verschiedenen Computersystemen nutzt, betrachtet REST dieses als Plattform für Computersysteme (Meyen 2010). Dabei wird beim REST-Ansatz zunächst von manuellen Interaktionen im Web ausgegangen. Tilkow (2009) führt daher auch als (trivialen) Vorteil an, dass man die Adresse einer Ressource in einem Browser mit einem Lesezeichen verknüpfen und dieses einem Kollegen schicken kann. Die Adressen einer REST-Applikation sind entweder alsphysische (z.B. IP-Adressen) oder alslogische (z.B. Domänennamen) Endpunkte von Ressourcen im Netz anzusehen. Ein Endpunkt ist eine über das Netzwerk zugängliche Adresse, über die eine Anwendung bereitgestellt wird.

Diese Ressourcenorientierung steht somit im Gegensatz zur Serviceorientierung, wo die adressierbaren Einheiten i.d.R. komplexere Services sind (vgl. Flieder 2008). Serviceorientierte Architekturen mit deren inhärenten Web-Service-Schnittstellen werden daher auch vornehmlich für das «Enterprise Computing» und E-Government eingesetzt, während sich REST sehr gut für das «Mobile Computing» eignet, wo ein schlankes Übertragungsprotokoll günstig ist. E-Commerce und Social Web Services sind typische Anwendungsfälle. Im SOA-Umfeld kommen für die Integration heterogener Informationssysteme neben unterschiedlichen Protokollen, wie z.B. HTTP, SMTP oder FTP auch unterschiedliche Middleware-Arten, z.B. asynchrones, persistierendes Messaging wie JMS, synchrone Remote Procedure Calls (RPC) sowie JDBC und ODBC in Frage. REST hingegen, das dem Paradigma der Ressourcenorientierung (ROA) folgt, nutzt ausschließlich das nicht persistierende Protokoll HTTP(S) mit seinen CRUD-Methoden.

Das REST-Prinzip sieht vor, mit Standard-Methoden des HTTP-Protokolls, wie GET, POST, PUT und DELETE, auf Ressourcen zuzugreifen. Eine Anfrage (Request), zum Beispiel nach einer bestimmten Bestellung, beinhaltet daher immer eine URL-Adresse sowie – transparent über den HTTP-Header – eine HTTP-Methode. Die URL ist unabhängig von der durchzuführenden Aktion zu betrachten, sie enthält in der Regel einen oder mehrere Parameter. Die in HTTP verfügbaren Methoden bilden sog. CRUD-Aktionen (C reate,R ead,U pdate undD elete) auf eine Ressource ab. Obwohl diese Aktionen bei Bedarf durch kleinere Modifikationen verändert werden können, stellt sich die CRUD-Funktionalität von REST wie folgt dar (vgl. Abts 2007; S. 153):

• HTTP POST:Create – diese Methode überträgt Benutzerdaten an eine Ressource.
  
• HTTP GET:Read – diese Methode fordert eine Ressource an, liest Daten von einer Ressource. EinRead entspricht einemGet, List oderRetrieve .
  
• HTTP PUT:Update – wird verwendet, um eine Ressource auf einen Server zu ändern.
  
• HTTP DELETE:Delete – wird verwendet, um eine bestehende Ressource zu löschen.
  
• HTTP OPTIONS: Liefert eine Liste mit den vom Server unterstützten Methoden.
  
• HTTP HEAD: Diese Methode fordert Informationen über eine Ressource.
  

Jede Ressource kann unterschiedliche Repräsentationen annehmen. Kundenstammdaten zum Beispiel können durch eine XML-Struktur oder im vcard-Format repräsentiert sein. Damit rückt bei REST der Multimedia-Gedanke in den Vordergrund, während SOAP-basierte Web Services – im Folgenden kurz SOAP-WS genannt – vornehmlich für entfernte Methodenaufrufe und den Datenaustausch konzipiert wurden. Zwischen Client und Server muss auch ein gemeinsames Verständnis über die Bedeutung der Repräsentation vorhanden sein. Bei SOAP-WS wird dies durch XML-basierte Nachrichten und entsprechender Schemata sichergestellt. Bei REST kann die Repräsentation einer Ressource auf weitere Ressourcen verweisen, man spricht dabei von einer Verkettung. Wenn ein Anwender einem Link folgt, gelangt er zu einer anderen Ressource. Dieses Prinzip ist aus der manuellen Interaktion mit dem Web bestens bekannt. REST Anwendungen können manuell, zum Beispiel über einen Browser, aber auch automatisiert, zum Beispiel über die Unix-/Linux-Programmecurl (Client for URLs) oderwget aufgerufen werden. Das Programmcurl steht zwar für die meisten Linux-Distributionen zur Verfügung, nicht jedoch für alle Unix-Derivate.

Abbildung 1: Funktionsschema von REST (Quelle:http://hinchcliffe.org/archive/2005/02/12/171.aspx ).

Wie SOAP-WS verwendet auch REST URIs zum Identifizieren von Ressourcen. Bei REST werden diese Ressourcen jedoch im Stile einer P2P-Architektur (Point-to-Point) miteinander verbunden. Der Einsatz in einer effizienteren H&S-Architektur (Hub-and-Spoke) ist zwar nicht ausgeschlossen, eine kryptografische Sicherung kann jedoch nur mittels HTTPS zwischen zwei Endpunkten erfolgen. Ein URI kann verschiedene Formen annehmen, zum Beispiel die folgende:

Der RFC 2396 beschreibt URIs näher und ist unter der folgenden Adresse abrufbar:

Für die Identifikation und Adressierung von Internet-Ressourcen werden Namensräume verwendet. Die Adressierung kann entweder über einen Uniform Resource Locator (URL), dieser gibt einen konkreten Hinweis zum Auffinden des Ortes oder über einen Uniform Resource Name (URN), das ist ein ortsunabhängiger Ausdruck, erfolgen. Diese Ortsunabhängigkeit ist insbesondere für die geforderte Eigenschaft der Ortstransparenz (Abschnitt 2.4) wichtig. Im Folgenden zwei Beispiele:

Darüber hinaus wird zwischen lokalen und qualifizierten Elementnamen unterschieden. Ein qualifizierter Name (QName) ist durch ein Präfix mit dem Namensraum verbunden. Tabelle 1 zeigt die Benennungen der einzelnen Teile einer Namensraumdefinition.

Tabelle 1: Teile einer Namensraumdefinition

Die Empfehlungen des W3C-Konsortiums zur Verwendung von Namensräumen finden sich unter der folgenden Adresse:

In einer Analogie betrachtet kann das Konzept der Namensräume mit der Namensgebung mit Vor- und Nachnamen verglichen werden. Alle Mitglieder einer Familie sind (als Gruppe) mit dem Nachnamen der Familie identifizierbar, z.B. die «Müllers». Will man nun jedoch die Mitglieder dieser Familie einzeln identifizieren, so wird zumindest ein weiterer Name benötigt – der Vorname. Man vergleiche dazu die folgende, fiktive Syntax: Peter.Müller vs. soap:Body. Ein anderes Beispiel aus der realen Welt sind Straßennamen. Um eine eindeutige Zuordnung treffen zu können, sollte es innerhalb eines Ortes nur eine «Hauptstraße» geben. Andererseits gibt es in verschiedenen Orten einen Straßenzug mit dieser Bezeichnung.

Ein großer Vorteil von SOAP-WS ist deren Verschiebbarkeit im Netz, die Ortstransparenz. Ein verteiltes System, das in der Lage ist, sich Benutzern und Applikationen so zu präsentieren, als handle es sich um ein einziges Computersystem, wird als transparent bezeichnet. Diese Transparenz kann verschiedene Facetten annehmen. Zum Beispiel Verteilungs-, Orts-, Relokations-, Zugriffs-, Migrations- oder Fehlertransparenz. Der Benutzer einer verteilten Anwendung muss den Ort des angefragten Objekts nicht kennen. Der ortsunabhängige (logische) Name enthält daher auch keine Informationen über den tatsächlichen (physischen) Speicherort. Ein Client kann die über einen Web Service angebotenen Dienste ohne vorherige Kenntnis ihrer Adresse nutzen. Die Ortstransparenz erfordert die Verwendung eines Namensdienstes (z.B. Domain Name Service – DNS). Für globale Objekte sind eindeutige, d.h. voll qualifizierte Namen erforderlich. Gemäß diesem Prinzip kann ein Service mit seinem Namen angesprochen werden, die IP-Adresse der konkreten Implementierung kann sich im Laufe der Zeit ändern. Zum Beispiel, wenn die Anwendung von einem Server zu einem anderen verschoben wird. Diese Form der Virtualisierung – Informationen können ohne fix codierte Bindung an eine reale Serviceadresse konsumiert werden – ist ein anerkannter Ansatz zur Bewältigung komplexer Umgebungen.

Die URL (Uniform Resource Locator) eines REST-Aufrufs besteht aus zwei Teilen: Der erste Teil enthält die Adresse des Service, der zweite Teil – im folgenden Beispiel fett gedruckt – die notwendigen Parameter:

Bei REST können URLs und Parameter direkt über Annotationen deklariert werden. Annotationen sind ein relativ neues Java-Sprachmittel und eine spezielle Form der deklarativen Programmierung. Mittels Annotationen können Geschäftsobjekte, z.B. ein Kunde, über einen URL adressiert werden. Da die Annotationen mit dem übrigen Code kompiliert werden, wird das Verhalten einer annotierten Klasse schon zur Entwicklungszeit festgelegt. Man spricht dabei auch von «früher Bindung». Diese Eigenschaft steht im Gegensatz zum Konzept der «späten Bindung», einer anerkannten Eigenschaft wie sie durch SOAP-WS unterstützt wird. Code-Beispiel 11 zeigt eine Beispielklasse, in Tabelle 2 werden ausgewählte Annotationen erklärt:

Code-Beispiel 1: Beispiele von Annotationen unter REST

Tabelle 2: Beispiele von Annotationen nach Israel (2010)

Beim Vergleich eines REST-Aufrufs mit SOAP sind zwar gewisse Parallelen festzustellen, SOAP-WS bieten jedoch mehr Flexibilität hinsichtlich Verschlüsselung, dem Routing von Nachrichten, der Spezifikation komplexer Parameter und des Transportprotokolls (Dunkel et al. 2008; S. 189). Ein Vorteil von RESTful Web Services tritt besonders bei Mashups zu Tage: Diese ermöglichen es, Benutzern auf Basis existierender Ressourcen im Web individuelle Applikationen zu erstellen. Zum Beispiel wird es durch die Kombination der Google-Maps-API¹ und der Atom-API möglich, einen neuen Service zu erstellen, der Listings auf einer Karte anzeigt. Neben REST und SOAP-WS kommen dafür auch noch Widgets und RSS Feeds in Frage.

Während bei REST eine Vielzahl nutzbarer MIME-Typen im Vordergrund steht, zielt die Argumentation zugunsten von SOAP-WS auf deren homogenisierende Eigenschaften ab, die durch den Einsatz von XML auf unterschiedlichen Abstraktionsebenen erreicht werden. Dadurch werden zwei wichtige Designprinzipien einer SOA unterstützt: Schnittstellenorientierung und Interoperabilität (Heutschi 2007; Flieder 2010).

HTTP gilt als zustandsloses Protokoll und definiert damit – sowohl für SOAP-WS als auch für REST – den Charakter einer zustandslosen Kommunikation. Der Server hat keine Kenntnis über vorangegangene Anfragen desselben Clients, jede Anfrage wird unabhängig von der vorhergehenden bearbeitet (vgl. Abts 2007; S. 150). REST nutzt lediglich die Methoden des zugrunde liegenden HTTP-Protokolls. Der Client erhält vom Server Statusmeldungen, die dieser auswerten kann. Alle notwendigen Informationen sind in den Repräsentationen der Ressourcen enthalten. Durch die Verkettung zwischen den Ressourcen besteht die Möglichkeit zu einer völlig anderen Anwendung zu gelangen. Durch das schlanke Protokoll und die geringe Bandbreite, die es benötigt, ist REST insbesondere für mobile Anwendungen – z.B. für den Zugriff auf virtuelle Güter – geeignet.

Während SOAP-WS vornehmlich für datenzentrierte Anwendungen eingesetzt werden, zielt REST auf den Anwendungsbereich mobiler und neuer Medien ab. Eine in der Praxis realisierte Integrationsanwendung mit REST ist die Einbindung von Apples iPhone als mobiles Endgerät in eine BPM-Umgebung (Business Process Management). Die zugrunde liegenden Konzepte sind bei SOAP-WS die Serviceorientierung (SOA) und bei REST die Ressourcenorientierung (ROA). Bekannte Anwendungen mit Fokus E-Commerce und Social Web nutzen REST. Teilweise parallel neben SOAP-WS, z.B. Amazon² , Flickr, Yahoo, Ebay und Google-Data-API.

SOAP-WS nutzen XML sowohl für die Servicebeschreibung (WSDL) als auch für das Nachrichtenformat (SOAP) und die Nutzdaten. In einer SOA-Umgebung kommt häufig die XML-basierte Ausführungssprache BPEL (Business Process Execution Language) zum Einsatz, wodurch inhaltsbasiertes Routing und andere Funktionalitäten für die Prozesssteuerung genutzt werden können. Eine Unterteilung der Funktionen in unterschiedliche Abstraktionsebenen macht deshalb Sinn: Konzeptebene (fachliche Gestaltung), Ausführungsebene, Dokumentenebene (Inhalte) sowie Protokollebene (Transport).

Für REST reicht eine Betrachtung der Protokoll- und der Dokumentenebene aus. Es ist lediglich ein Protokoll möglich, dafür können jedoch verschiedene Dokumentenformate genutzt werden.

Bei REST kann es durch nebenläufig ausgeführte Transaktionen zu folgenden Fehlersituationen kommen: Lost-Update, Dirty-Read, Unrepeatable-Read und Phantoms. Diesen Anomalien kann am besten mit geeigneten Synchronisierungstechniken begegnet werden. (vgl. Mandl 2009 S. 238-240 bzw. Abts & Mülder 2010; S. 610).

Bei den Interaktionen zwischen verteilten Anwendungen über SOAP-WS ist auf die sog. Fehlersemantiken («Delivery Semantics») Best Effort, At-Least-Once, At-Most-Once und Exactly-Once abzustellen. Um eine garantierte Zustellung über unsichere Transportprotokolle zu implementieren, sind je nach geforderter Zuverlässigkeit geeignete Kompensationsmaßnahmen notwendig.

Für ein Demonstrationsbeispiel wurde aus den verfügbaren Java-Implementierungen (Jersey, RESTEasy, Apache CXF und Restlet³ ) Jersey⁴ für eine beispielhafte Implementierung ausgewählt. Jersey ist die Referenzimplementierung des unter der Bezeichnung JAX-RS («Java API for RESTful Web Services») bzw. JSR 311⁵ standardisierten Application Programming Interfaces (API) für die Implementierung von RESTful Web Services mit der Programmiersprache Java. Diese API arbeitet mit Annotationen (Abschnitt 2.5), die über zugehörige Klassen und Interfaces ausgewertet werden. Dieses Programmiermodell wird Plain Old Java Objects (POJOs)⁶ ,⁷ genannt. Jersey unterstützt automatisches «Content-Negotiation» auf Basis mehrerer Mime/Media-Typen⁸ («Hypermedia»), URI-Templates sowie verschiedener HTTP-Methoden und erlaubt damit eine flexible Typisierung von Parametern bei der Kodierung. Die JAX-RS-Runtime kümmert sich um die Konvertierung zwischen Java-Objekten und gängigen Repräsentationen von elektronischen Dokumenten. Die JAX-RS-API unterstützt die Bibliothek JAXB (Java API for XML Binding) für das Binding von XML- oder JSON-Dokumenten⁹ auf die Objekte einer Programmiersprache wie Java. Zwar schlägt Microsoft für die .NET-basierte Entwicklung von REST-Applikationen das Windows Communication Framework (WCF)¹⁰ vor, doch die treibenden Kräfte gehen derzeit eindeutig von der Java-Community aus. Dennoch kann der REST-Ansatz ebenso wie SOAP-WS als programmiersprachen- und plattformunabhängig betrachtet werden.

Im vorliegenden Beitrag wurden unter Bezugnahme auf eine beispielhafte Java- Implementierung die grundlegenden Funktionalitäten von RESTful Web Services (Representational State Transfer) skizziert und ausgewählte Eigenschaften gegenüber klassischen, SOAP-basierten Web Services dargestellt. RESTful Web Services, die auf eine klar definierte Menge an Funktionen des HTTP-Protokolls zurückgreifen, wurden als leichtgewichtige und funktional einfachere Alternative zu SOAP-basierten Web Services vorgestellt. Diese Eigenschaften verleihen REST Stärken, die für den Handel mit virtuellen Gütern vor allem im mobilen E-Commerce und im Social Web von hoher Relevanz sind.

Abts, Dietmar; Mülder, Wilhelm: Masterkurs Wirtschaftsinformatik. 1. Auflage, Vieweg+Teubner, Wiesbaden (2010).
Abts, Dietmar: Masterkurs Client/Server-Programmierung mit Java. 2. Auflage, Vieweg & Sohn, Wiesbaden (2007).
Dunkel, Jürgen; Eberhart, Andreas; Fischer, Stefan; Kleiner, Carsten; Koschel, Arne: Systemarchitekturen für verteilte Anwendungen: Client-Server, Multi-Tier, SOA, Event-Driven Architectures, P2P, Grid, Web 2.0. Carl Hanser Verlag, München (2008).
Fielding, Roy T.; Taylor, Richard N.: Principled Design of the Modern Web Architecture. ACM Transaction on Internet Technology, Vol. 2. (2), S. 115-150 (2002).
Fielding, Roy T.: Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine,www.ics.uci.edu/~fielding/pubs/dissertation/top.htm aufgerufen 22. Oktober 2010 (2000)
Flieder, Karl: Interoperabilität durch Web Services. ERP-Management, Heft 1, S. 43-45 (2010).
Flieder, Karl: Serviceorientierte Softwarearchitekturen in Theorie und Praxis. In: e&i Elektrotechnik & Informationstechnik 126 (12), Springer-Verlag Berlin, Heidelberg, New York, S. a32-a35 (2009).
Flieder, Karl: LDAP-Verzeichnisse: ein unterschätztes Sicherheitsrisiko? In: Schweighofer, E.; Geist, A.; Heindl, G.; Szücs, C. (Hrsg.): Komplexitätsgrenzen der Rechtsinformatik, OCG, Wien, S. 83-91 (2008).
Heutschi, Roger: Serviceorientierte Architektur – Architekturprinzipien und Umsetzung in der Praxis. Springer, Berlin Heidelberg (2007).
Higashino, Wilson A.; Felgar de Toledo, Beatriz; Capretz, Miriam A. M: REST and Resource-Oriented Architecture. In: Alt R.; Fähnrich K.-P.; Franczek B. (Eds.): Proceedings of First International Symposium on Service Science ISSS’09, Logos-Verlag, Berlin (2009).
Israel, Tobias: RESTlos glücklich.http://www.buschmais.de/media/2010/03/restlos-gluecklich.pdf aufgerufen 3. Januar 2011 (2010).
Leitner, Peter; Grechenig, Thomas: Club-, Live- und Videoshopping: Die Eroberung des Onlinehandels durch innovative Social Commerce Konzepte. In: Schweighofer, E. (Hrsg.): Semantisches Web und Soziale Netzwerke im Recht, OCG, Wien, S. 63-67 (2009).
Mandl, Peter: Masterkurs Verteilte betriebliche Informationssysteme – Prinzipien, Architekturen und Technologien. Vieweg+Teubner, 1. Auflage, Wiesbaden (2009).
Meyen, Sebastian: REST oder SOAP? Java-Magazin Heft 01, S. 4 (2009).
Sackmann, Stefan; Strüker, Jens: Electronic Commerce Enquête 2005: 10 Jahre Electronic Commerce - Eine stille Revolution in deutschen Unternehmen. IIG-Telematik, Universität Freiburg, Konradin IT-Verlag, Leinfelden (2005).
Tilkow, Stefan: Der bessere Web Service? Javamagazin Heft 01, S. 74-80 (2009).

---

Karl Flieder, Student, Master-Studiengang Wirtschaftsinformatik, Ferdinand Porsche FernFH Wien – Wiener Neustadt, Lothringerstrasse 4-8, 1040 Wien, AT
eai@karlflieder.at

Stefan Sackmann, Inhaber des Lehrstuhls für Wirtschaftsinformatik, insb. Betriebliches Informationsmanagement, Martin-Luther-Universität Halle Wittenberg, Universitätsplatz 10, 06099 Halle/Saale, DE
stefan.sackmann@wiwi.uni-halle.de

---