1 Einleitung

Die Verfechter von Webservices sahen sichin der Vergangenheit oftmals der Frageausgesetzt, ob der vermeintlich große tech-nische Aufwand, den SOAP, WSDL,UDDI usw. darstellen, fur das Ziel eineranwendungs- und unternehmensubergrei-fenden Systemkommunikation nicht unan-gemessen sei. Statt dessen solle ein Web-service doch einfach durch einen URIadressiert werden und ein Ergebnis perHTTP liefern. Dieser Ansatz wird meistals „REST-Webservice“ bezeichnet. DerBegriff REST geht zuruck auf Roy Field-ing und hat ursprunglich nichts mit Web-services zu tun.Mit dem Schlagwort REST ist die Dis-

sertation von Roy Fielding aus dem Jahr2000 bekannt geworden. In seiner Arbeitmit dem Titel „Architectural Styles and theDesign of Network-based Software Archi-tectures“ [Fiel00] untersucht er Architek-turdesigns von netzbasierten Anwendun-gen. Ein Ziel seiner Arbeit besteht darin,Richtlinien zu entwickeln, um fur einen ge-gebenen Anwendungsfall die geeignete Ar-

chitektur wahlen bzw. schaffen zu konnen.Zu diesem Zweck betrachtet Fielding sol-che Qualitatskriterien wie Performance,Skalierbakeit, Einfachheit, �nderbarkeit(im Sinne von Weiterentwickelbarkeit, Er-weiterbarkeit, Anpassbarkeit, Konfigurier-barkeit, Wiederverwendbarkeit), Portabili-tat, Zuverlassigkeit.Als Architekturstil einer netzbasierten

Anwendung definiert Fielding eine „Men-ge von architektonischen Eckdaten, die dieRollen und Features von Architekturele-menten und den erlaubten Beziehungenzwischen solchen Elementen innerhalb ei-ner zu diesem Stil konformen Architekturbeschranken.“ Seine Dissertation unter-sucht die genannten Qualitatskriterien furArchitekturstile unter den Aspekten desDatenflusses (Data-flow), ihrer Replika-tionseigenschaften (repliziertes Repositoryoder Cache-Architektur), des Hierarchien-stils (etwa Client-Server versus LayeredSystem oder Layered-Client-Server), deseventuell vorhandenen mobilen Codes(von der virtuellen Maschine bis zu mo-bilen Agenten) sowie der Peer-to-Peer-Eigenschaften.Ein wichtiger Teil von Fieldings Arbeit

und hinsichtlich des Bekanntheitsgradesseiner Dissertation der bekannteste Teilkonzentriert sich auf das World Wide Webals Anwendungsbeispiel eines verteiltenHypermedia-Systems. Fieldings Ansatzsoll zweierlei Zielen dienen: Einerseits ver-folgt er ein deskriptives Ziel, namlich dieBeschreibung der Webarchitektur gemaßseiner zuvor aufgestellten Methodik, ande-rerseits geht es um ein konstruktives Ziel.Vorgeschlagene Veranderungen der Web-architektur (wie etwa Weiterentwicklungenvon HTTP) sollen sich hinsichtlich ihrerAuswirkungen und Effizienz untersuchenlassen, indem der Architekturstil des vor-handenen Webs mit dem Architekturstildes vorgeschlagenen Webs verglichen undbewertet werden.

Soviel als �berblick uber Fieldings Ar-beit. Ein Aspekt, um den es im Folgendengehen soll, erregte Aufsehen unter Kriti-kern des Nachrichtenstandards SOAP, weiler vermeintlich Overhead des SOAP-An-satzes vermeidet.

2 RepresentationalState Transfer (REST)

Unter der Abkurzung REST ist der vonFielding beschriebene Architekturstil „Re-presentational State Transfer“ bekannt ge-worden. Die Dissertation entwickelt diesenStil aus der Beobachtung der Architekturdes World Wide Web. Vereinfacht be-schreibt Fielding RESTals eine Architekturmit folgenden Eigenschaften:1) Eine REST-Architektur basiert auf dem

Client-Server-Modell.2) Die Kommunikation ist zustandslos.3) Caches werden zur Performance-Ver-

besserung eingesetzt. Dies erfordert,dass Daten in der Kommunikation alscacheable oder non-cacheable gekenn-zeichnet sind.

4) Eine einheitliche Schnittstelle zwischenden Komponenten ist die zentrale Ei-genschaft von REST. Diese Verallgemei-nerung der Komponentenschnittstelletragt zur Vereinfachung des Systemsund zur Verbesserung der Sichtbarkeitder Interaktionen bei. Implementierun-gen werden von den Services, die siedarstellen, entkoppelt, was zu einerunabhangigen Weiterentwickelbarkeitfuhrt. Nachteile sind die geringere Ef-fizienz, da der Informationsaustauschzwischen den Komponenten einesREST-Systems in einer standardisiertenWeise und nicht in einer auf die Anwen-dungen zugeschnittenen Weise erfolgt.

5) Um Anforderungen im Internetmaßstabzu erfullen, ist ein REST-System ein ge-

WIRTSCHAFTSINFORMATIK 47 (2005) 1, S. 63–65

Der Autor

Stefan Mintert

Dipl.-Inform. Stefan MintertBerater fur vernetzte InformationInhaber von Linkwerk.com, Hamburgstefan.mintert@linkwerk.com

Implementierung von WebservicesREST vs. SOAP?

WI – Schlagwort

schichtetes System (layered system). Vor-teile sind die Kapselung von Legacy-Systemen und die Einfuhrung von In-termediaren, etwa fur das Load-Balancing.

6) Schließlich bezieht sich die Code-On-Demand-Eigenschaft von REST im Fal-le WWW auf Java-Applets oder Java-Script-Programme.

3 Implementierung vonWebservices

In den vergangenen Jahren hat sich nun ei-ne interessante Diskussion zwischen denREST- und den SOAP-Anhangern ent-wickelt. Bemerkenswert ist aber zunachst,dass sich uberhaupt zwei Lager gebildethaben. Ausgangspunkt durften folgendeFeststellungen gewesen sein:1) Das REST-Prinzip ist außerordentlich

einfach.2) SOAP-Nachrichten sind recht aus-

schweifend, nicht zuletzt wegen ihrerXML-Grundlage; bereits in den Zielenvon XML 1.0 heißt es „Terseness inXML markup is of minimal impor-tance.“

3) Einige, insbesondere fruhe SOAP-Bei-spiele lassen sich ohne SOAP, nur mitHTTP-GET realisieren.

SOAP dient dem Nachrichtenaustausch,etwa in RPC-Szenarien (Remote ProcedureCall). Beispiel: Eine Satz von Parametern

wird als Nachricht an eine entfernte Pro-zedur ubergeben, sie berechnet das Ergeb-nis und schickt es als Nachricht zuruck.Ein beliebtes Beispiel, das in vielfaltiger Va-riation bereits in einem fruhen Papier derXML-Protocol-Arbeitsgruppe zu findenist, ist das Abfragen des Kurses eines bor-sennotierten Unternehmens [W3C01]. DasPapier enthalt den in Bild 1 dargestelltenCode fur den Request sowie den in Bild 2dargestellten Code fur die Antwortnach-richt.Es ist offensichtlich, dass sich dieses Bei-

spiel problemlos ohne SOAP, unter Ein-satz von HTTP-GET realisieren lasst. TimBerners-Lee hat in einer Diskussion desThemas den SOAP-Request exemplarischin folgende Form gebracht:http://example.org/SoapGet?serv=http://example.org/2001/06/quotes&Symbol=DEFAls Antwortnachricht solle die zuvor ge-

zeigte XML-Instanz ubertragen werden.Die prinzipielle �bertragbarkeit der-

artiger Beispiele in die eine (SOAP) oderdie andere Form (GET) muss hier nichtdiskutiert werden, ebensowenig die offen-sichtlichen Probleme wie fehlende Typi-sierung von Daten in URIs, Langen-beschrankungen und so weiter. Wesentlichist, dass es unter einem naiven Blickwinkeleine �quivalenz der beiden Ansatze gibt.Das Beispiel der Aktienkurse fur SOAP-Nachrichten ist vielleicht auch deshalb un-glucklich gewahlt, weil es einen solchen Ser-vice auf Basis von HTTP, GET und XML

langst gab: Die NASDAQ hatte ihn bereitsfruh eingefuhrt. So war zum Beispiel unterhttp://quotes.nasdaq.com/quote.dll?page=xml&mode=stock&symbol=RHAT derKurs der Red-Hat-Aktie zu erfragen. Wie„page=xml“ andeutet, handelte es sich beider Antwortnachricht nicht um eine Web-seite in HTML, sondern um eine Beschrei-bung des Borsenkurses in XML. Im Okto-ber 2004 steht der Dienst leider nicht mehrzur Verfugung. Die zugrunde liegendeDTDist jedoch immer noch unter http://nasdaq.com/reference/NasdaqDotCom.dtdeinzusehen. Elliotte Harold beschreibt denNASDAQ-Dienst inklusive exemplari-scher Nachrichten [HARO2002].Die zuruckliegenden Ausfuhrungen soll-

ten zeigen, wie es zur Diskussion uberREST vs. SOAP gekommen ist: es wurdeimplizit HTTP-GET mit REST gleichge-setzt. Da das GET immer einen URI alsParameter verwendet, gilt es, URIs naherzu betrachten. Fielding schreibt in seinerDissertation, dass URIs die Rolle der Be-zeichner (identifiers) von REST ausfullen.Er schreibt aber auch, dass URIs in einemnicht zu REST konformen Sinne eingesetztwerden. Ein Beispiel ist die Kodierung ei-ner User-ID in einem URI. Diese Informa-tion steht jedoch in keiner Beziehung zuder Ressource, die mit dem URI bezeich-net wird. Es gibt also URIs, die nicht derREST-Architektur folgen.Hervorzuheben ist hier, dass Fielding

von Ressourcen spricht. Das ist auch nichtuberraschend, wenn man betrachtet, fur

WIRTSCHAFTSINFORMATIK 47 (2005) 1, S. 63–65

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"><env:Body>

<r:GetLastTradePrice env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"xmlns:r="http://example.org/2001/06/quotes">

<r:Symbol>DEF</r:Symbol></r:GetLastTradePrice>

</env:Body></env:Envelope>

Bild 1 Code fur den Request

<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"><env:Body>

<r:GetLastTradePriceResponse env:encodingStyle="http://www.w3.org/2001/12/soap-encoding"xmlns:r="http://example.org/2001/06/quotes"xmlns:rpc=”http://www.w3.org/2001/12/soap-rpc”>

<rpc:Result>34.5</rpc:Result>lt;/r:GetLastTradePriceResponse>

</env:Body></env:Envelope>

Bild 2 Code fur die Antwortnachricht

64 Stefan Mintert

welchen Bereich er REST entwirft: „Thischapter introduces and elaborates the Re-presentational State Transfer (REST) archi-tectural style for distributed hypermediasystems [. . .].“ Die Diskussion um SOAPversus REST scheint durch eine weitgehen-de Missachtung der ursprunglich verschie-denen Ansatze entstanden zu sein: RESTbetrachtet Ressourcen, die „geGETed“werden, SOAP betrachtet Nachrichtenaus-tausch z. B. fur RPCs. Es gibt Anwen-dungsfalle, in denen beide Sichtweisen glei-chermaßen geeignet sind, die Aufgabe zulosen. Das Beispiel des Aktienkurses ist einsolcher Fall. Es gibt aber auch andere Falle.Im zuvor zitierten Text von Berners-Leeschreibt er in Klammern: „Although I’mbeginning to wonder if so-called Web Ser-vices really have anything to do with theWeb.“In [McMi03] stellt Sam Ruby, Web-

services-Entwickler bei IBM, seinen Stand-punkt zu den vermeintlich gegensatzlichenSichtweisen dar:„I think they [REST and Web services]

actually can play nice together. You can ac-tually say, »I will use REST to describehow objects are accessed«, and then useSOAP to talk about how those objects arerepresented.One interesting thing is that REST

stands for Representational State Transfer,and one thing that REST does not talk atall about is how you actually represent thestate, despite the fact that that’s the name.Conversely, Simple Object Access Proto-col (SOAP) does not talk about any way inwhich you access objects; it just talks abouthow you represent state and do transfer.So, you have two groups of people not

talking to one another, but talking pasteach other. If you actually combine thebest ideas of both, you end up with an ex-tensible and modular and loosely coupledsystem.“

An anderer Stelle bringt Ruby den Un-terschied zwischen REST und SOAP aufzwei einfache Formeln [Ruby02]:1) REST – SOAP ¼ XLink2) SOAP – REST ¼ Stored ProceduresSein Artikel ist fur einen tieferen Einstiegin das Thema lesenswert, weil er hilft, dasAugenmerk auf die wesentlichen Eigen-schaften beider Ansatze zu lenken und sichnicht in der schlichten Entweder-Oder-Diskussion zu verstricken.

4 Resumee

Roy Fielding stellt in seiner Dissertation inForm seines Architekturstils namens RESTeine abstrahierte Beschreibung der Web-Architektur vor. Die daraus entstandeneDiskussion, ob REST (im Sinne vonHTTP-GET) oder SOAP die bessereGrundlage fur Webservices seien, lehrtletztlich nur eine nicht sehr neue Weisheit:Die Wahl der (technischen) Mittel solltedem Problem angemessen sein und dieDinge sollten nicht komplizierter gemachtwerden als unbedingt notwendig. REST istmit seiner minimalistischen Sichtweise gutgeeignet, das Auge zu scharfen, um dieKomplexitat netzbasierter Anwendungenniedrig zu halten. Eine Alternative zuSOAP-basierten Webservices ist RESTnicht; nicht zuletzt, weil dazu mehr gehortals nur SOAP (etwa WSDL, UDDI). Dieswar auch nicht Fieldings Ansatz oder Ziel.Wer der Diskussion vollig aus dem Weg

gehen mochte, kann die Herangehensweisevon Amazon kopieren, sofern die Prob-lemstellung dies zulasst: Amazon bieteteinfach einen REST- und SOAP-Web-service [Amaz04]. Der Internethandlerstellt Partnern seine Webservice-Schnitt-stelle in beiden Auspragungen zur Ver-fugung, wobei Amazon seinen REST-An-

satz konkretisierend als „XML overHTTP“ bezeichnet. Auf einen mittelsHTTP-GET abgesetzten Request liefertAmazon eine XML-Response. Dass dieSchnittstelle mittlerweile in Version 4 ange-boten wird, deutet darauf hin, dass seitensder Nutzer kein eindeutiger Trend fur nureine der beiden Auspragungen besteht.

Abschließend sei bemerkt, dass die Ein-fachheit der REST-Beschreibung sich auchin der Dokumentation von Amazon wider-spiegelt: Das Kapitel uber die Migrationzur neuen Version 4 stellt die Unterschiedezur fruheren Version nur im REST-Stil vor.Warum? – Weil sich die Beschreibung hierauf die Auflistung von URIs beschrankenkann. Noch kurzer lasst sich die Schnitt-stellenbeschreibung kaum fassen.

Literatur

[Amaz04] Amazon E-Commerce Service 4.0,2004-10-19,http://www.amazon.com/gp/aws/sdk/

[Bern02] Berners-Lee, T.: whenToUseGet, Mailin-glistendiskussion, 2002-04-21,http://lists.w3.org/Archives/Public/www-tag/2002Apr/0211.html

[Fiel00] Fielding, R.: Architectural Styles and theDesign of Network-based Software Architec-tures. Dissertation 2000, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[Haro02] Harold, E.: Processing XML with Java,2002, Kapitel 2, http://www.cafeconleche.org/books/xmljava/chapters/ch02s04.html

[McMi03] McMillan, R.: Web services visionary.Interview mit Sam Ruby, 2003-06-17,http://www-106.ibm.com/developerworks/webservices/library/ws-samruby.html

[Ruby02] Ruby, S.: RESTþSOAP, interwingly.net,2002-07-20, http://www.intertwingly.net/stories/2002/07/20/restSoap.html

[W3C01] Ibbotson, J. (Hrsg.): XML ProtocolUsage Scenarios, W3C Working Draft, 2001-12-17, http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/

WIRTSCHAFTSINFORMATIK 47 (2005) 1, S. 63–65

Implementierung von Webservices – REST vs. SOAP? 65