Außer den sichtbaren Websites findet im Web auch unauffällige Kommunikation statt: Über Webservices tauschen Programme Informationen aus, von Warenkatalogen bis hin zu Klatsch und Tratsch.

Alltag im WWW: Die Preissuchmaschine findet das günstigste Angebot, ein Softwareportal zeigt die Wohnorte der Entwickler auf einer Weltkarte. Hinter solchen Features steckt meist ein Webservice. Das heißt schlicht, dass ein Programm mit einem anderen per HTTP Informationen austauscht. Die Dienste verwenden standardisierte Verfahren und Datenformate, sodass sie die Grenzen einzelner Plattformen, Technologien und Programmiersprachen überwinden.

Soap & Co.

Nach einer engeren Definition handelt es sich bei Webservices um Interaktionen, die das XML-Nachrichtenformat Soap verwenden, das derzeit in Version 1.2 aus dem Jahr 2003 gültig ist [1]. Das Akronym stand einst für Simple Object Access Protocol, hat sich aber mittlerweile als eigenes Wort etabliert.

Soap hat seine Wurzeln im Remote Procedure Call (RPC) der als XML-RPC seit Ende der neunziger Jahre HTTP als Transportmechanismus und XML als Nachrichtenformat verwendet [2]. Dabei handelt es sich um eine recht einfache Abbildung von Methoden und Datentypen auf ein XML-Format. Der anfragende Rechner schickt einen »methodCall« -Knoten per HTTP-»POST« ab und erhält als Antwort einen »methodResponse« -Knoten mit den gewünschten Ergebnisdaten oder einer Fehlermeldung.

Die Weiterentwicklung Soap reichte Microsoft mit einigen Verbündeten 2000 beim World Wide Web Consortium (W3C) ein. Es erweitert die Nachrichten um Envelope und Header, funktioniert sowohl per HTTP als auch SMTP und kennt Datei-Attachments. Daneben besitzt es ein erheblich umfangreicheres XML-Vokabular.

Listing 1 stammt aus der W3C-Recommendation und zeigt die Soap-Anfrage an einen Reisedienstleister. Der Envelope umschließt Header (Zeile 3 bis 15) und Body (Zeile 16 bis 38). Die eigentliche Buchungsanfrage für den Flug ist in einem unter »http://travelcompany.example.org/reservation/travel« definierten XML-Format kodiert und enthält Start- und Zielort, Terminwunsch und Tageszeit sowie Sitzplatzwunsch für die Flugreise (»itinerary« , Zeile 17 bis 33). Der Knoten »lodging« steht für eine optionale Hotelbuchung zur Verfügung.

01 <?xml version='1.0' ?>
02 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
03  <env:Header>
04   <m:reservation xmlns:m="http://travelcompany.example.org/reservation"
05           env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
06            env:mustUnderstand="true">
07    <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
08    <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
09   </m:reservation>
10   <n:passenger xmlns:n="http://mycompany.example.com/employees"
11           env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
12            env:mustUnderstand="true">
13    <n:name>Åke Jógvan Øyvind</n:name>
14   </n:passenger>
15  </env:Header>
16  <env:Body>
17   <p:itinerary
18     xmlns:p="http://travelcompany.example.org/reservation/travel">
19    <p:departure>
20      <p:departing>New York</p:departing>
21      <p:arriving>Los Angeles</p:arriving>
22      <p:departureDate>2001-12-14</p:departureDate>
23      <p:departureTime>late afternoon</p:departureTime>
24      <p:seatPreference>aisle</p:seatPreference>
25    </p:departure>
26    <p:return>
27      <p:departing>Los Angeles</p:departing>
28      <p:arriving>New York</p:arriving>
29      <p:departureDate>2001-12-20</p:departureDate>
30      <p:departureTime>mid-morning</p:departureTime>
31      <p:seatPreference/>
32    </p:return>
33   </p:itinerary>
34   <q:lodging
35    xmlns:q="http://travelcompany.example.org/reservation/hotels">
36    <q:preference>none</q:preference>
37   </q:lodging>
38  </env:Body>
39 </env:Envelope>

Um Soap herum haben sich weitere Technologien und Standards ausgebildet, die man oft als WS-*-Stack zusammenfasst. Zu den wichtigsten gehört WSDL, die Webservices Description Language. Ebenfalls in XML abgefasst, beschreibt sie einen zur Verfügung stehenden Dienst. Liefert ein Diensteanbieter WDSL, macht er den Entwicklern eine Freude: Java und Microsofts Dotnet-Framework besitzen Generatoren, die anhand der WSDL-Beschreibung automatisch den Großteil des Codes für einen passenden Client produzieren. Daneben gibt es Soap-Implementierungen für Programmiersprachen wie PHP, Perl, Ruby und andere.

Dicke Dienste

Kritiker von Soap & Co. bezeichnen diese Technologien als “dicke” Webservices. Sie bemängeln den Vokabelreichtum und Umfang der XML-Botschaften, die der Programmierer zudem mit Parsern und einer eigenen Abfragesprache wie Xpath verarbeiten muss.

Der Gegenvorschlag heißt Representational State Transfer (REST) und setzt direkt auf dem WWW-Protokoll HTTP auf. Im Jahr 2000 beschrieb ihn der Informatiker Roy Fielding in seiner Doktorarbeit [3]. Fielding ist einer der Gründer des Apache-Projekts, zudem war er maßgeblich an der Entwicklung des HTTP-Protokolls beteiligt.

REST sieht für jede Ressource, beispielsweise einen Foreneintrag oder ein Produkt in einem Online-Shop einen Uniform Resource Identifier (URI) vor. So könnte ein Produkt beispielsweise unter »http://example.com/products/Produktnummer« zu finden sein. Das elegante an diesem Ansatz: Er stellt keinen Bruch zu dem dar, was auch ansonsten im WWW üblich ist, beispielsweise beim schlichten Aufrufen einer statischen Webseite per HTTP-»GET« . Um mit diesen Ressourcen zu arbeiten, verwendet REST weitere HTTP-Methoden, auch als Verben bezeichnet, als Vokabular. Mit den wichtigsten lassen sich Einträge anlegen, lesen, ändern oder löschen (Tabelle 1). Dabei kommt »PUT« zum Einsatz, wenn das Anlegen oder Ändern durch Senden des gesamten Ressourceninhalts erfolgt, »POST« dagegen kann auch eine serverseitige Prozedur aufrufen – und mischt damit ein RPC-Element in die REST-Welt.

REST und das neu geschaffene Adjektiv RESTful erfreuen sich unter Softwareentwicklern in den letzten Jahren großer Beliebtheit. Anwendungsbeispiele für diese Architektur sind der Simple Storage Service (S3) von Amazon, der Request Tracker RT und auch die NoSQL-Datenbank Couch DB. REST-Implementierungen finden sich für so gut wie jede aktuelle Programmiersprache, von diversen Java-Frameworks über Cake PHP und Fuel PHP bis zu Web2py und Ruby on Rails. Sogar ein Stück Javascript auf einer Webseite kann als REST-Client arbeiten, wie das Framework Ext JS zeigt. Der Perl-Snapshot in der Programmieren-Rubrik dieses Linux-Magazins nutzt Mojolicous, um den Dienst Google Drive mit Perl anzusprechen.

Abseits der reinen REST-Lehre stellen viele Schnittstellen zu Webanwendungen allerdings Mischformen dar. Sie kombinieren HTTP-»GET« mit serverseitigen Methodenaufrufen. Das kennt jeder, der schon einmal URIs der Bauart »http://localhost/app?entry=15&action=delete« fabriziert hat.

Datenquellen

Sei es Soap, REST oder eine hybride Methode – viele Websites lassen sich dank ihres Web-API als Datenquelle nutzen. Das Titelthema dieses Linux-Magazins-beschreibt mit Schnittstellen zu sozialen Netzwerken, E-Commerce-Software, Entwicklertools und geografischen Informationensystemen die wichtigsten Anwendungsszenarien.

Wer sich nur mit seinem eigenen Bugtracker verbindet, muss außer der Technik wenig anderes bedenken. Bezieht er aber Kartendaten oder Preisinformationen von einem kommerziellen Anbieter, gilt es, auch die juristischen Rahmenbedingungen zu beachten. So gesehen gehört der auch Rechtsartikel “Hintertüren” in diesem Magazin noch zum Titelthema.