Analyse SOAP vs. REST

Transkript

1 Dokumentation Analyse SOAP vs. REST Version 1.0, Bernd Zwattendorfer Zusammenfassung: Im Internet werden Web Services für den Nachrichten- Austausch und die Kommunikation zwischen Systemen eingesetzt. Die zwei wesentlichen Standards dafür sind SOAP und REST. In diesem Dokument werden sowohl SOAP als auch REST ausführlicher erläutert. Anschließend werden beide Ansätze miteinander verglichen und deren Unterschiede bzw. deren Vor- und Nachteile dargestellt. E-Government Innovationszentrum Inffeldgasse 16/a, A-8010 Graz Tel Fax Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

2 Inhaltsverzeichnis 1 Einleitung SOAP Struktur von SOAP-Nachrichten Austausch von SOAP-Nachrichten Beispiel Vor- und Nachteile Vorteile Nachteile REST Struktur von REST-Nachrichten Austausch von REST-Nachrichten Beispiel Vor- und Nachteile Vorteile Nachteile SOAP vs. REST Implementierung Austauschformat Transportprotokoll Schnittstellenbeschreibung Frameworks Unabhängigkeit von der Umgebung Performance Sicherheit Zustandsbehaftung Transaktionen Anwendungsgebiet Fehlerbehandlung Spezifizierte Erweiterungen Zusammenfassung und Fazit Einleitung 2

3 Abbildungsverzeichnis Abbildung 1 - Web Service Kommunikation... 4 Abbildung 2 - Aufbau einer SOAP-Nachricht... 5 Abbildung 3 - Funktionsweise von SOAP Abbildung 4 - Funktionsweise von REST Tabellenverzeichnis Tabelle 1 Beispiel einer SOAP-Request-Nachricht [Hüff10]... 7 Tabelle 2 - Beispiel einer SOAP-Response-Nachricht [Hüff10]... 7 Tabelle 3 Beispiel einer REST-Request-Nachricht [Hüff10] Tabelle 4 - Beispiel einer REST-Response-Nachricht [Hüff10] Tabelle 5 - Zusammenfassung SOAP vs. REST Einleitung 3

4 1 Einleitung SOAP [SOAP 1.2] und REST [Fiel00] definieren im Wesentlichen zwei Standards für Web Services. Während das Web zu Beginn hauptsächlich für den Informationstransfer zwischen einer Benutzerin bzw. einem Benutzer und einem oder mehreren Servern verwendet wurde, wird seit etlichen Jahren das Web auch für den Austausch von Informationen zwischen Servern bzw. Systemen genutzt. Diese Kommunikation zwischen den Systemen bzw. die zugrundeliegende Web-Schnittstelle wird dabei als Web Service bezeichnet. Das W3C als treibende Kraft hinter der Spezifizierung von Web Standards definiert Web Services folgendermaßen: The World Wide Web is more and more used for application to application communication. The programmatic interfaces made available are referred to as Web services. [WS_Act] Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. [WS_Arch] Eine Web Service-Kommunikation besteht im Wesentlichen aus dem Nachrichtentransfer zwischen zwei Endpunkten, einem Web Service-Client und einem Web Service-Server. Dabei sendet der Client einen Web Service-Request an den Server, dieser bearbeitet die Anfrage und sendet eine Web Service-Response zurück an den Client. Abbildung 1 veranschaulicht dieses Szenario. Web Service-Request Web Service-Response Bearbeitung Web Service Client Web Service Server Abbildung 1 - Web Service Kommunikation Für die Kommunikation zwischen Web Service-Client und Web Service-Server können unterschiedliche Möglichkeiten herangezogen werden. Zwei dieser Möglichkeiten sind SOAP und REST. Im Rahmen dieses Dokuments werden SOAP bzw. REST kurz beschrieben und deren Eigenschaften bzw. Vor- und Nachteile miteinander verglichen. Einleitung 4

5 2 SOAP SOAP [SOAP 1.2] ist ein zustandsloses, XML-basiertes Protokoll für den Nachrichtenaustausch in verteilten Systemen. Die aktuelle Version ist SOAP 1.2. Durch die Verwendung von XML ermöglich SOAP einen Nachrichtenaustausch unabhängig von der verwendeten Programmiersprache bzw. vom verwendeten Programmiermodell und dessen Implementierung. SOAP ist kein reines Anwendungsoder Transportprotokoll sondern setzt vielmehr auf existierende Protokolle für den Nachrichtentransport. Das am meisten verwendete Protokoll für den Transfer von SOAP- Nachrichten ist HTTP. Es ist aber auch möglich, SOAP-Nachrichten über andere Protokolle zu transportieren, wie z.b. SMTP oder FTP. Die ursprüngliche Idee von SOAP war der Austausch von Remote Procedure Calls (RPCs). Remote Procedure Calls erlauben innerhalb eines Programms den Aufruf von Funktionen auf entfernten Rechnern oder Systemen. SOAP ist deshalb auch aus dem Standard XML-RPC 1 entstanden. SOAP wird aber nicht rein für RPCs verwendet, sondern vielmehr für den einfachen Informationsaustausch auf Basis von XML zwischen Systemen. 2.1 Struktur von SOAP-Nachrichten SOAP-Nachrichten bestehen aus einem sogenannten SOAP-Header und einem SOAP- Body. SOAP-Header und SOAP-Body werden in einem sogenannten SOAP-Envelope zusammengefasst. Abbildung 2veranschaulicht diesen Aufbau. SOAP-Envelope SOAP-Header XML-Header Information SOAP-Body XML-Nachricht Abbildung 2 - Aufbau einer SOAP-Nachricht 1 SOAP 5

6 Der SOAP-Body ist verpflichtend und enthält dabei die eigentliche XML-Nachricht, die ausgetauscht werden soll. Der SOAP-Header ist optional und kann zusätzliche Informationen zur Nachricht im SOAP-Body enthalten, z.b. wie diese verarbeitet werden soll. Des Weiteren kann der SOAP-Header Informationen zum Transport der Nachricht beinhalten, z.b. wie die Nachricht transportiert oder geroutet werden soll, wenn die Nachricht nicht direkt zum Empfänger sondern über Intermediäre geschickt wird. Das SOAP-Envelope ist im Wesentlichen nur ein Element, das die Elemente SOAP-Header und SOAP-Body kapselt Austausch von SOAP-Nachrichten Der Austausch von SOAP-Nachrichten erfolgt über zwei Endpunkte, dem SOAP-Sender und dem SOAP-Empfänger. Dabei schickt der SOAP-Sender eine SOAP-Nachricht an den SOAP-Empfänger. Der SOAP-Empfänger bearbeitet die empfangene Nachricht und retourniert eine entsprechende SOAP-Nachricht als Antwort. Kann die empfangene Nachricht nicht beantwortet werden oder ist fehlerhaft, so wird eine Fehlermeldung (SOAP Fault) an den SOAP-Sender geschickt. Es ist auch möglich, die SOAP-Nachricht nicht direkt vom Sender zum Empfänger zu schicken, sondern über einen Intermediär zu leiten. Dieser Intermediär kann eventuell die Nachricht bearbeiten, bevor sie dem SOAP-Empfänger zugestellt wird. Um die technischen Details bzw. generell die Funktionalität einer Web Service- Schnittstelle zu beschreiben, wird meist die XML-basierende Web Services Description Language (WSDL) [WSDL] herangezogen. Eine WSDL-Datei stellt maschinenlesbare Informationen zur Verfügung, wie ein Web Service aufgerufen werden kann, welche Parameter es erwartet bzw. welche Datenstrukturen retourniert werden. WSDL wird häufig im Zusammenhang mit SOAP verwendet, SOAP stellt aber nur eine Binding- Variante wenn auch die fast ausschließlich verwendete dar. Für das Auffinden von Web Services und deren WSDL-Beschreibung wird üblicherweise UDDI (Universal Description, Discovery and Integration) [UDDI] verwendet. UDDI ist ebenfalls eine plattformunabhängige, XML-basierte Spezifikation für Register, welche Mechanismen zum Registrieren und Auffinden von Web Services bereitstellen. Die Kommunikation mit einem UDDI-Register erfolgt ebenfalls mittels SOAP-Nachrichten. 2.3 Beispiel Die folgenden Tabelle 1 und Tabelle 2 zeigen ein Beispiel einer SOAP-Request- und SOAP-Response-Nachricht. Das Beispiel ist zum Großteil von [Hüff10] übernommen und zeigt die Abfrage eines Standorts z.b. eines mobilen Geräts. Die fett hervorgehobenen Elemente kennzeichnen SOAP-Header, SOAP-Body, sowie das umschließende SOAP- Envelope. Die restlichen Elemente stellen die eigentliche über SOAP ausgetauschte SOAP 6

7 Nachricht dar (im SOAP-Body) sowie zusätzliche Verarbeitungsinformationen der Nachricht (im SOAP-Header). In diesem Beispiel werden beide Nachrichten über HTTP übertragen. POST /service/ HTTP/1.1 Host: Content Type: application/xml Content Length: 156 Tabelle 1 Beispiel einer SOAP-Request-Nachricht [Hüff10] <env:envelope xmlns:env" <env:header> <ns:priority xmlns:ns=" </env:header> <env:body> <ns:requestlocation xmlns:ns=" </env:body> </env:envelope> HTTP/ OK Content Type: application/xml Content Length: 270 Tabelle 2 - Beispiel einer SOAP-Response-Nachricht [Hüff10] <S:Envelope xmlns:s=" <S:Header/> <S:Body> <ns:requestlocationresponse xmlns:ns=" <location> <latitude>1</latitude> <longitude>2</longitude> </location> </ns:requestlocationresponse> </S:Body> </S:Envelope> Zur Veranschaulichung von REST wird dasselbe Beispiel verwendet, um die Unterschiede besser zu illustrieren (siehe Abschnitt 0). 2.4 Vor- und Nachteile Dieser Abschnitt beschreibt einige Vor- und Nachteile von SOAP Vorteile Dieser Abschnitt beschreibt einige Vorteile von SOAP. SOAP 7

8 Unabhängigkeit von der Umgebung SOAP erreichte vor allem deswegen so eine Popularität, da es unabhängig von der Plattform, vom Betriebssystem, von der Programmiersprache und vom darunterliegenden Transportprotokoll verwendet werden kann. SOAP-Nachrichten können beispielsweise über HTTP, FTP, SMTP, etc. übertragen werden. Weiters ist es egal, ob ein SOAP-Endpunkt in Java, PHP, etc. geschrieben wurde, die Kommunikation ist interoperabel. [Suda03] XML-Basiert SOAP ist XML-basiert und erbt somit die wichtigsten Vorteile und Eigenschaften auch von XML. Dies inkludiert die Form und Struktur von XML-Dokumenten, sowie deren menschen- und gleichzeitig maschinenlesbare Form. Dazu kommen noch die strukturierten Beschreibungsmöglichkeiten von Web Services mittels WSDL oder UDDI. [Suda03] Just in Time Service-Zusammenstellung SOAP Web Services sind üblicherweise nicht streng miteinander, sondern eher lose gekoppelt. Dies bietet die Möglichkeit, Services bei Bedarf aufzufinden und dynamisch miteinander zu verbinden bzw. in Applikationen zu integrieren. Services können aufgrund ihrer WSDL-Beschreibung auch einfach ausgetauscht werden. [Suda03] Versionierung Obwohl die SOAP Spezifikation mit Nummern zur Versionierung versehen ist, gibt es keine derartige Nummerierung zur Kennzeichnung der SOAP Version im SOAP-Envelope Element. Vielmehr verlässt sich die SOAP-Spezifikation auf den verwendeten XML- Namespace-URI im SOAP-Envelope. Das Resultat ist, dass man keine genaue Aussage über die Version treffen kann, sondern nur sagen kann, ob die Version gleich oder unterschiedlich ist. Dieses Vorgehen wurden von den Entwicklern von SOAP explizit gewählt und erlaubt ein flexibleres Verhalten von Web Service Implementierungen. [GDS+04] Nachteile Dieser Abschnitt beschreibt einige Nachteile von SOAP Nachrichtengröße Obwohl XML einige Vorteile bringt, bringt es auch einiges an Overhead mit sich, sodass die übertragene Nachricht wesentlich größer ist als der reine Informationsgehalt. Dies ist vor allem ein beträchtlicher Nachteil, wenn große Daten übertragen werden sollen und die Bandbreite begrenzt ist. XML kann aber auch die Performance beeinträchtigen, da SOAP 8

9 das Parsen von XML und das Umwandeln von XML in Objekte und vice versa doch einiges an Rechenleistung benötigt. [Suda03] Latenzzeit Wird eine SOAP-Nachricht nicht direkt zum Empfänger geschickt sondern über mehrere Knoten geroutet, so muss jeder Knoten die SOAP-Nachricht parsen, um die Header- Informationen zu lesen, welche Informationen für die weitere Bearbeitung der Nachricht beinhalten können. Bei geringer Bandbreite von Verbindungen kann dies leicht zu Problemen oder Engpässen führen. [Suda03] Formalität SOAP-Nachrichten bzw. Schnittstellen sind durch die Verwendung von XML-Schema zur Beschreibung sehr stark spezifiziert. D.h. nur entsprechend dem Service angepasste Clients können die Nachrichten verarbeiten. Änderungen im Service bedingen daher üblicherweise auch Änderungen im Client. [Hüff10] SOAP 9

10 3 REST Mit REST (Representational State Transfer) [Fiel00] wird kein eigenes Protokoll oder Standard für Web Services bezeichnet, sondern ein eigener Architekturstil für das Internet bzw. Web. REST wurde von Roy Fielding im Rahmen seiner Dissertation im Jahr 2000 entworfen. REST setzt in seiner Architektur auf ein Client-Server-Modell. Dabei kann ein Client auf Ressourcen, die von einem Server bereitgestellt werden, via HTTP zugreifen. REST unterstützt kein anderes Transportprotokoll. Bereitgestellte Ressourcen sind beispielsweise normale HTML-Seiten, Bilder, aber auch XML-Dokumente. All diese Ressourcen sind über eine URL adressiert und können vom Client darüber angesprochen und abgerufen werden. Für den Zugriff auf diese Ressourcen werden keine eigenen Befehle definiert, sondern jene, die von HTTP bereits zur Verfügung stehen. Diese Befehle sind im Wesentlichen GET, POST, PUT und DELETE. Nach [Wiki_REST] können aber auch noch andere HTTP-Befehle für die Kommunikation verwendet werden. 3.1 Struktur von REST-Nachrichten Für REST-Nachrichten existiert keine eigene Spezifikation oder Struktur, sie sind vielmehr einfache HTTP-Request- und HTTP-Response Nachrichten, die zwischen Client und Server ausgetauscht werden. Eine REST-Request-Nachricht ist somit beispielsweise ein einfacher HTTP-GET-Request auf eine Ressource, die über eine URL adressiert wird. Die HTTP-Response enthält in diesem Fall die Ressource, z.b. einen einfachen Text oder ein Bild. Es besteht jedoch die Möglichkeit, anhand des MIME-Types eine Unterscheidung für den Rückgabetyp der Response zu treffen. Dabei gibt der Client im HTTP-Request den gewünschten MIME-Type mit und der Server antwortet sofern implementiert beispielsweise je nach angegebenen MIME-Type entweder mit einer HTML-Seite oder einem XML-Dokument [KlMa04]. 3.2 Austausch von REST-Nachrichten REST-Nachrichten sind einfache HTTP-Nachrichten, wobei keine besondere Nachrichten-Struktur vorgeschrieben ist. Es können beliebige Daten zwischen Client und Server ausgetauscht werden. Für den Austausch von Nachrichten werden hauptsächlich die von HTTP vorgegeben Kommandos GET, POST, PUT und DELETE verwendet. Ein Client kann diese Befehle verwenden um am Server Ressourcen abzurufen (GET), zu verändern (POST), neu zu erstellen (PUT), oder zu löschen (DELETE). Um den Austausch von REST-Nachrichten einfacher zu erklären, wird auf ein Warenkorb-Beispiel in einem Onlineshop nach [Baye02] und [Fron11] zurückgegriffen. REST 10

11 Die Artikel (Ressourcen) des Onlineshops sind dabei alle über eine URL adressiert und verfügbar. GET: HTTP-Request: GET /artikel/1234 Mit diesem HTTP-GET-Befehl ruft der Client vom Server Informationen zum Artikel mit der Nummer 1234 ab. Der Server antwortet mit entsprechenden Informationen. Nachdem kein Standard für die Repräsentation des Artikels vorgegeben ist, kann die Artikelinformation z.b. als HTML, XML, etc. dem Client retourniert werden. Zwischen Client und Server muss jedoch ein gemeinsames Verständnis über die Repräsentation vorhanden sein. Eine HTTP-Response, die Artikel-Informationen als XML zurückliefert, könnte z.b. wie folgt aussehen: HTTP-Response: HTTP/ OK Content-Type: text/xml <?xml version="1.0"?> <artikel xlink:href= nr="1234"> <buch>e-government ABC</buch> <preis>100</preis> </artikel> POST: HTTP-Request: POST /artikel/warenkorb/3333 artikelnummer=0815 Dieser POST-Befehl fügt zum Warenkorb mit der Nummer 3333, dessen Inhalt z.b. mit einem GET/warenkorb/3333 abgerufen werden kann, den Artikel mit der Nummer 0815 hinzu. HTTP-Response: HTTP/ OK Content-Type: text/xml <?xml version="1.0"?> <warenkorb xlink:href= nr="3333" <artikel xlink:href= nr="1234"> <buch>e-government ABC</buch> <preis>100</preis> </artikel> <artikel xlink:href= nr="0815"> <buch>it Sicherheitshandbuch</buch> <preis>100</preis> REST 11

12 </artikel> </warenkorb> Mit der HTTP-Response und dem HTTP-Status Code 200 wird angezeigt, dass der Befehl erfolgreich ausgeführt und der Artikel dem Warenkorb hinzugefügt wurde. Abhängig von der Serverimplementierung, kann der gesamte Warenkorb mit dem hinzugefügten Artikel dem Client in der Antwort zurückgeliefert werden, wie hier gezeigt. PUT: HTTP-Request: PUT /artikel <artikel xlink:href= nr="2345"> <buch>moa-mocca</buch> <preis>100</preis> </artikel> Mit dem PUT-Befehl kann ein neuer Artikel mit der Nummer 2345 am Server als Ressource hinzugefügt werden. HTTP-Response: HTTP/ OK Content-Type: text/xml; Content-Length: 30 Der HTTP-Status Code 201 gibt an, dass der Artikel am Server erfolgreich als neue Ressource hinzugefügt wurde. Der restliche Inhalt der HTTP-Response enthält die URL zum neu angelegten Artikel. DELETE: HTTP-Request: DELETE /artikel/2345 Mit dem HTTP-DELETE-Befehl kann man Ressourcen am Server löschen. Hier wird der zuvor hinzugefügte Artikel mit der Nummer 2345 wieder gelöscht. HTTP-Response: HTTP/ OK Die HTTP-Response gibt einfach nur an, dass der Artikel erfolgreich gelöscht wurde. Über die URL ist der Artikel nun nicht mehr erreichbar. 3.3 Beispiel Die folgende Tabelle 3 und Tabelle 4 zeigt dasselbe Beispiel einer Ortsabfrage (wie in Abschnitt 2.3 für SOAP) nur mittels REST. Der fett markierte Pfad (/location) gibt dabei den Aufruf des REST-Services an. Außer dem Aufruf der URL und der Angabe des MIME- REST 12

13 Types enthält der HTTP-Request keine weiteren Informationen. In der HTTP-Response wird auch nur reines XML übertragen, ohne Overhead-Informationen wie bei SOAP. GET /service/location HTTP/1.1 Host: Accept: application/xml Tabelle 3 Beispiel einer REST-Request-Nachricht [Hüff10] HTTP/ OK Content Type: application/xml Content Length: 73 <location> <latitude>1</latitude> <longitude>2</longitude> </location> Tabelle 4 - Beispiel einer REST-Response-Nachricht [Hüff10] 3.4 Vor- und Nachteile Dieser Abschnitt beschreibt einige Vor- und Nachteile von REST Vorteile Dieser Abschnitt beschreibt einige Vorteile von REST Unabhängigkeit von der Umgebung Wie SOAP ist auch die Verwendung von REST unabhängig von der zugrundeliegenden Plattform, vom Betriebssystem oder von der Programmiersprache. Dies liegt vor allem an der Verwendung von HTTP als Transportprotokoll Unabhängigkeit der Clients REST-Clients benötigen keine spezielle Funktionalität, sie müssen im Endeffekt nur HTTP sprechen können. Ändert sich eine Funktion am Service, so muss der Client nicht sofort angepasst werden, da sich die HTTP-Funktionen nicht ändern Skalierbarkeit Durch die Zustandslosigkeit von REST ist eine hohe Skalierbarkeit gegeben. Des Weiteren erhöht die Möglichkeit eines flexiblen Hinzufügens von Ressourcen die Skalierbarkeit. [Hüff10] REST 13

14 3.4.2 Nachteile Dieser Abschnitt beschreibt einige Nachteile von REST Fehlende Standardisierung [Hüff10] kritisiert bei REST die fehlende Standardisierung. REST-Services und deren Schnittstellen können zwar mittels WADL (Web Application Description Language) [WADL] konkreter beschrieben werden, für die Beschreibung von Ressourcen fehlt aber solch eine standardisierte Möglichkeit Kein Verzeichnisdienst REST-Services sind eher rein für Client-Server-Verbindungen ausgelegt und nicht für verteilte Umgebungen. In REST gibt es keinen Verzeichnisdienst, wo REST-Services und deren Funktionalität beschrieben sind und von dort aus abgerufen werden können. Neue Services können nur über URLs angeboten werden. [Alda10] REST 14

15 4 SOAP vs. REST In diesem Abschnitt wird SOAP und REST anhand unterschiedlicher Kriterien miteinander verglichen. Bevor ein Vergleich durchgeführt wird, wird nochmals der grundlegende Unterschied in der Funktionsweise dargelegt. Der Nachrichtenaustausch zwischen Client und Server erfolgt bei SOAP nämlich anders als bei REST. Die für die Veranschaulichung verwendeten Darstellungen sind an [Baye02], [Fron11], und [KlMa04] angelehnt. HTTP Client HTTP Server SOAP-Sender SOAP-Empfänger Objekte/ Ressourcen SOAP-Request1 POST /soap/router Objekt1 SOAP-Request2 /soap/router Objekt2 SOAP-Request3 Objekt3 Abbildung 3 - Funktionsweise von SOAP Abbildung 3 illustriert schematisch die allgemeine Funktionsweise von SOAP. Es wird davon ausgegangen, dass HTTP als Transportprotokoll verwendet wird. SOAP-Request- Nachrichten werden von einem SOAP-Sender (HTTP Client) mittels HTTP-POST-Befehl an den SOAP-Empfänger (HTTP Server) übertragen. Alle Request-Nachrichten werden an denselben Endpunkt (/soap/router) geschickt. Der SOAP-Empfänger extrahiert die Nachricht und entscheidet dann auf Basis der enthaltenen Funktion, welche Ressource bzw. welches Objekt angesprochen werden soll bzw. für die Abarbeitung des Requests benötigt wird. D.h. alle eingehenden Nachrichten werden zuerst beim SOAP- Empfänger gebündelt und nach Anschauen des Inhalts entsprechend weitergeleitet. SOAP vs. REST 15

16 HTTP Client HTTP Server REST-Client REST-Server Objekte/ Ressourcen GET /objekt1 HTTP-Request1 /objekt1/* Objekt1 GET /objekt2 HTTP-Request2 /objekt2/* Objekt2 HTTP-Request3 POST /objekt3 /objekt3/* Objekt3 Abbildung 4 - Funktionsweise von REST Abbildung 4 veranschaulicht die allgemeine Funktionsweise von REST. Wie für REST notwendig, wird auch hier HTTP für die Übertragung von Nachrichten verwendet. Wesentlicher Unterschied zu SOAP ist, dass ein Objekt bzw. eine Ressource mittels HTTP- Befehl und passender URL direkt angesprochen werden kann. D.h. die Nachrichten werden nicht wie bei SOAP gebündelt, sondern der REST-Server (Web Server) kann direkt anhand der URL unterscheiden, welche Ressource angesprochen werden will. Auch für die Auswahl der entsprechenden Funktion muss die eingehende Nachricht nicht geöffnet werden. [KlMa04] und [Baye02] stellen den Unterschied in der Funktionsweise zwischen SOAP und REST relativ einfach anhand eines klassischen Briefbeispiels dar. Bei SOAP werden alle Briefe zuerst an die Firmenadresse geschickt, dort geöffnet, und anhand des enthaltenen Adressaten an die eigentliche Person weitergeleitet. Im Gegensatz dazu werden bei REST alle Briefe direkt an die jeweilige Person übermittelt. In den folgenden Unterabschnitten wird nun SOAP und REST anhand unterschiedlicher Kriterien verglichen. 4.1 Implementierung SOAP benötigt üblicherweise mehr Implementierungsaufwand als REST, da in SOAP zwingend XML umgesetzt werden muss, wohingegen bei REST der Nachrichten-Inhalt flexibler gestaltet werden kann. Außerdem muss bei REST keine eigene Schnittstelle definiert werden, da diese durch das HTTP-Protokoll vorgegeben ist. Nach [KlMa04] erfordert SOAP einen stärkeren Zusammenhang zwischen Client und Server. Ändert sich das SOAP-Interface beim Server, so muss auch der Client dementsprechend neu angepasst werden. Bei Verwendung von REST ist dies nicht notwendig. Ändert sich eine SOAP vs. REST 16

17 Ressource oder kommt eine neu hinzu, ist es nur notwendig, die entsprechende URL zur Ressource anzupassen. Das restliche Interface bleibt gleich. 4.2 Austauschformat Bei SOAP ist XML zwingend als Nachrichtenformat vorgeschrieben. Natürlich können innerhalb von SOAP-Nachrichten auch andere Formate wie Text oder beliebige Daten in Base64-kodierter Form übertragen werden. Binäre Daten können in SOAP aber auch einfach als Attachment an ein SOAP-Envelope angehängt werden, wie in [SOAP_Att] oder [MTOM] spezifiziert. REST ist hier flexibler und spezifiziert kein Format für den Austausch von Inhalten. Hier kommt aber oft JSON 2 (JavaScript Object Notation) zum Einsatz, ein einfaches und textbasierendes Datenaustauschformat. Prinzipiell kann über den MIME-Type auch angegeben werden, welches Austauschformt für Daten in einer HTTP-Response verwendet werden soll. 4.3 Transportprotokoll SOAP-Nachrichten können über unterschiedliche Transportprotokolle übertragen werden, wie z.b. HTTP, FTP, oder SMTP. Hier ist von SOAP mehr Flexibilität gegeben als von REST, welches von seiner Architektur aus nur eine Verwendung von HTTP vorsieht. 4.4 Schnittstellenbeschreibung SOAP-Schnittstellen können einfach durch ein WSDL-File formal syntaktisch beschrieben werden. Eine WSDL-Beschreibung einer SOAP-Schnittstelle ist programmiersprachenunabhängig und enthält beispielsweise Input- und Output- Nachrichten sowie zu verwendende Bindings. Im Endeffekt, sind jede SOAP-Schnittstelle und deren Nachrichten über ein XML-Schema detailliert beschrieben. Eine Schnittstellenbeschreibung von REST-Services ist nur zum Teil standardisiert möglich [Horn11]. Ähnlich wie für SOAP kann für REST-Services WADL herangezogen werden. WADL ist ebenfalls XML-basiert und für die Beschreibung von HTTP-basierten Services ausgelegt. Eine WADL-Beschreibung enthält z.b. die vom Server zur Verfügung gestellten Ressourcen, deren Zugriffsbefehle und notwendige Parameter. Eine standardisierte Möglichkeit zur Beschreibung von Ressourcen existiert nicht. 2 SOAP vs. REST 17

18 4.5 Frameworks Für SOAP existieren seit Jahren bereits entsprechende Frameworks und Libraries. Bekannte Vertreter, vor allem in der Java-Umgebung sind Apache Axis 3 oder JAX-WS 4 (JSR 224), eine Java-API zum Erstellen von Web Services mit zugehöriger Referenz- Implementierung (Metro). Für REST existiert auch eine entsprechende Java-API namens JAX-RS 5 (JSR 311), für die auch eine Referenzimplementierung mit dem Namen Jersey 6 existiert. 4.6 Unabhängigkeit von der Umgebung Sowohl SOAP als auch REST sind von der Umgebung unabhängig. Es gibt in beiden Fällen keine Notwendigkeit eine bestimmte Plattform zu verwenden, ein bestimmtes Betriebssystem zu verwenden, oder das Service in einer bestimmten Sprache zu programmieren. Dies liegt einerseits an der Verwendung von XML und andererseits an der Verwendung von HTTP als Transportprotokoll. 4.7 Performance SOAP hat hier den Nachteil, dass durch die Verwendung von XML ein relativ großer Overhead entsteht, einerseits in der Datenmenge und andererseits durch das performance-intensive Parsen von XML. Das Verhältnis von Nutzdaten zu Gesamtdaten ist bei der Verwendung von SOAP wesentlich höher als bei REST, nimmt aber mit zunehmender Größe der Nutzdaten ab. Bei SOAP existiert beispielsweise ein eigener Header, welcher zusätzliche Informationen enthalten kann. REST beschränkt zusätzliche Information auf HTTP-Header. Bei SOAP muss auch jede Nachricht geparsed werden, bevor sie weitergeleitet oder verarbeitet wird. Bei REST muss der Nachrichteninhalt zur Weiterleitung nicht angesehen werden. Nachdem REST z.b. HTTP-GET verwendet (SOAP verwendet nur HTTP-POST), können solche Nachrichten auch am Client bei Bedarf gecached werden. Dies kann auch einen entsprechenden Performance-Vorteil bringen. [KlMa04] 4.8 Sicherheit Sowohl REST- als auch SOAP-Nachrichten können bei Verwendung HTTP Firewalls ohne Probleme passieren. REST bietet hier aber vor allem auf Firewall-Ebene mehr Möglichkeiten, Anfragen zu blockieren oder sperren. Soll beispielsweise der Zugriff auf eine Ressource nicht erlaubt sein, so muss in der Firewall nur die adressierende URL SOAP vs. REST 18

19 gesperrt werden. Dasselbe gilt für HTTP-Befehle. Soll auf eine Ressource nur lesend zugegriffen werden, so wird mittels Firewall nur der HTTP-GET-Befehl erlaubt und alle anderen gesperrt. Bei Verwendung von SOAP ist eine Zugriffsregelung aufs Web Service mittels Firewall nicht möglich. Bei SOAP muss zuerst in der Anwendung die Nachricht angesehen werden, bevor entschieden werden kann, ob die aufrufende Funktion erlaubt wird oder nicht. [KlMa04] Zum Absichern von SOAP Web Services eignet sich WS-Security (WSS) [WSS], eine Spezifikation, die beispielsweise beschreibt, wie Nachrichten verschlüsselt oder signiert werden können. Verschlüsselung oder die Absicherung der Nachricht erfolgt bei REST üblicherweise auf Transportebene unter Verwendung von SSL/TLS. Natürlich kann auch bei SOAP auf SSL/TLS gesetzt werden. Die Verwendung von WS-Security bietet aber die Möglichkeit von Ende-zu-Ende-Sicherheit auch bei Verwendung von Intermediären, was durch reine Verwendung von SSL/TLS nicht möglich ist. 4.9 Zustandsbehaftung Sowohl SOAP als auch REST sind vom Protokoll her zustandslos. Bei REST ergibt sich diese serverseitige Zustandslosigkeit durch die Verwendung von HTTP. Bei SOAP kann man unter Umständen eine Zustandsbehaftung erreichen, z. B. wenn bestimmte IDs in die Header der SOAP-Nachrichten kodiert werden Transaktionen Nachdem die Serverbeschaffenheit von REST und SOAP zustandslos ist, ist es auch schwierig, Transaktionen abzubilden. Nach [KlMa04] können aber in REST extra Ressourcen angelegt werden, mit denen Transaktionen modelliert werden können. So wird diese Ressource dann am Beginn und am Ende von zusammenhängenden Aktionen aufgerufen, um diese Transaktion abbilden zu können. Bei der Verwendung von SOAP ist das Abbilden von Transaktionen einfacher, da die notwendigen Vorkehrungen dafür in die SOAP-Nachrichten kodiert werden können. Eine Möglichkeit ist nach [Horn11] WS-Reliable Messaging (WSRM) [WSRM] Anwendungsgebiet Nach [Horn11] werden REST-Services eher für datenorientierte und synchrone Services mit kurzer Laufzeit eingesetzt. Eine asynchrone Kommunikation ist nach [Horn11] nicht direkt möglich und kann nur über Umwege simuliert werden. Im Gegensatz dazu eignen sich SOAP Services sowohl für datenorientiere als auch prozessorientierte Anwendungen. Die Services können dabei auch eine längere Laufzeit besitzen und vom Timing her synchron oder asynchron sein. Eine asynchrone Kommunikation kann beispielsweise über WS-Notification [WSN] erreicht werden. SOAP vs. REST 19

20 4.12 Fehlerbehandlung SOAP hat Fehlermeldungen (SOAP Faults) bereits in seiner Spezifikation eingebaut. Üblicherweise wird vom SOAP-Server eine detaillierte Fehlerbeschreibung an den SOAP-Client retourniert. REST hingegen hat kein explizites Error-Handling sondern übernimmt lediglich die Status-Codes von HTTP. Eine genaue Beschreibung des Fehlers ist hier nicht möglich Spezifizierte Erweiterungen SOAP ist ein Standard, der vom W3C spezifiziert ist und zu dem auch zahlreiche Spezifikationen zur Erweiterung definiert sind. Häufig verwendete Erweiterungen sind beispielsweise SOAP with Attachments [SOAP_Att], SOAP Message Transmission Optimization Mechanism [MTOM], oder die Spezifikationen aus der WS*-Familie wie z.b. WS-Security [WSS] oder Web Services Reliable Messaging [WSRM]. REST hingegen ist nur ein Architekturstil, der rein die Funktionen von HTTP verwendet und somit auf diese limitiert ist. Es existieren somit keine spezifizierten bzw. standardisierten Erweiterungen zu REST. SOAP vs. REST 20

21 5 Zusammenfassung und Fazit SOAP und REST sind beides unterschiedliche Ansätze für das Abbilden von Web Services. Unterschiede sowie Vor- und Nachteile der einzelnen Ansätze wurden bereits erläutert. Aufgrund des unterschiedlichen Zugangs kann keine klare Aussage getroffen werden, ob für Web Services SOAP oder REST verwendet werden soll. Der Einsatz des jeweiligen Ansatzes hängt einfach von unterschiedlichen Faktoren oder Anforderungen ab. So wird REST nur für Punkt-zu-Punkt-Verbindungen eingesetzt, während SOAP in verteilten Umgebungen auch unter Verwendung von Intermediären Einsatz finden kann. Von der Performance her hat REST gewisse Vorteile, da XML nicht verwendet werden muss und so performance-teures XML parsen vermieden werden kann. Außerdem kann ohne Verwendung von XML Datenoverhead bei der Übertragung vermieden werden. Dies macht REST interessant vor allem für den Einsatz in mobilen Clients, wo Bandbreite üblicherweise limitiert ist. Die Verwendung von XML hat aber auch seine Vorteile, da SOAP-Schnittstellen formal und syntaktisch beschrieben werden können. Nichtsdestotrotz sind dadurch Clients sehr stark an den Server gebunden, wobei bei REST Änderungen am Server für den Client nicht so stark ins Gewicht fallen. SOAP bietet hingegen wiederum mehr Möglichkeiten der Erweiterung, da sehr viele Spezifikationen dazu (z.b. die WS*-Standards) bereits existieren. Ende-zu-Ende-Sicherheit ist so beispielsweise realisierbar (durch WS-Security), während bei REST die Sicherheit auf Transportebene (unter Verwendung von SSL/TLS) abgewälzt wird. Durch zusätzliche Erweiterungen bei SOAP lässt sich auch eine asynchrone Kommunikation bzw. Transaktionen realisieren, was bei REST nur durch Umwege und kompliziert erreichbar ist. Zusammenfassend kann gesagt werden, dass REST überall dort verwendet werden sollte, wo Web Services schnell, ohne viel Overhead und Implementierungsaufwand, und unter Verwendung von HTTP erstellt werden sollen. SOAP sollte hingegen dort verwendet werden, wo komplexere Prozesse abgebildet werden müssen, eine formale Schnittstellenbeschreibung notwendig ist, und der Implementierungsaufwand bzw. Bandbreite keine Rolle spielen. Tabelle 5 gibt abschließend eine Übersicht für die wichtigsten Unterschiede zwischen SOAP und REST. Weiterführende Vergleiche und Übersichtstabellen sind unter beispielsweise unter [Alda10], [Horn11], [Mota13] oder [Sand10] zu finden. Zusammenfassung und Fazit 21

22 Tabelle 5 - Zusammenfassung SOAP vs. REST Kriterium SOAP REST Implementierungsaufwand höher geringer Austauschformat XML Beliebig (XML, HTML, JSON, Text, etc.) Transportprotokoll HTTP, FTP, SMTP, etc. HTTP Schnittstellenbeschreibung WSDL, XML-Schema WADL Frameworks (Java) JAX-WS (Metro) JAX-RS (Jersey) Unabhängigkeit von der Umgebung unabhängig Performance schlechter gut unabhängig Sicherheit WS-Security, SSL/TLS Über Firewall- oder Web Server-Einstellungen, SSL/TLS Zustandsbehaftung zustandslos, aber Umständen zustandsbehaftet zustandslos Transaktionen über WS-Reliable Messaging über zusätzliche Ressourcen Anwendungsgebiet datenorientiere als auch prozessorientierte synchrone oder asynchrone Services mit längerer Laufzeit datenorientierte und synchrone Services mit kurzer Laufzeit Fehlerbehandlung SOAP Faults HTTP Status-Codes Spezifizierte Erweiterungen WS*-Familie, MTOM, etc. Keine Zusammenfassung und Fazit 22

23 Dokumentenhistorie Version Datum Autor(en) Anmerkung Bernd Zwattendorfer Bernd Zwattendorfer Dokumenterstellung Erster Draft Arne Tauber Kommentare Bernd Zwattendorfer Finale Version Zusammenfassung und Fazit 23

24 Referenzen [Alda10] Sascha Alda: Service-Orientierte Architekturen - Kapitel 8: REST, 2010, [Baye02] Thomas Bayer: REST Web Services Eine Einführung, 2002, [Fiel00] Roy Thomas Fielding: Architectural Styles and the Design of Network-based Software Architectures, 2000, [Fron11] Nicole Fronhoffs: Webservices : SOAP und REST, 2011, [GDS+04] Steve Graham, Doug Davis, Simeon Simeonov, Glen Daniels, Peter Brittenham, Yuichi Nakamura, Paul Fremantle, Dieter Koenig, Claudia Zentner: Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI, 2nd Edition [Horn11] Torsten Horn: RESTful Web Services mit JAX-RS und Jersey, 2011, [Hüff10] Marc Hüffmeyer: Verteilte und mobile Applikationen - Arbeitsgebiet 3: Verteilte mobile Dienste in Next Generation Networks, 2010, &Itemid=91 [KlMa04] Thomas Kloster, Oskar Martin: Vergleich SOAP und REST, 2004, osnabrueck.de/fileadmin/compass/lehrveranstaltungen/sose_04/soap- Rest_Ausarbeitung.pdf [Mota13] Jagadeesh Motamarri: Compare RESTful vs SOAP Web Services, 2013, [MTOM] W3C: SOAP Message Transmission Optimization Mechanism, 2005, [Sand10] [SOAP 1.2] Sebastian Sander: Performanceanalyse von SOAP- und REST- basierten Services in einer Linguistic Resources Umgebung, 2010, W3C: SOAP Version 1.2, 2007, [SOAP_Att] W3C: SOAP 1.2 Attachment Feature, 2004, [Suda03] Brian Suda: SOAP Web Services, 2003, [UDDI] OASIS: OASIS UDDI Specification TC, 2005, [WADL] W3C: Web Application Description Language, 2009, [Wiki_REST] Wikipedia: Representational State Transfer, [WS_Act] W3C: Web Services Activity, 2008, [WS_Arch] W3C: Web Services Architecture, 2004, [WSDL] W3C: Web Services Description Language (WSDL) Version 2.0, 2007, Zusammenfassung und Fazit 24

25 [WSN] OASIS: OASIS Web Services Notification (WSN) TC, [WSRM] OASIS: OASIS Web Services Reliable Messaging (WSRM) TC, [WSS] OASIS: OASIS Web Services Security (WSS) TC, Zusammenfassung und Fazit 25