Seite 3: SOAP, das XML-Ungetüm

Inhaltsverzeichnis

Im Zuge der großen Aufmerksamkeit für XML entstand Ende der 1990er-Jahre SOAP, das im Rahmen serviceorientierter Architekturen noch immer beliebt ist. SOAP ist nichts anderes als eine mit XML abstrahierte und kombinierte Variante von RPC. Im Vordergrund steht zwar mehr der Austausch klar strukturierter Daten zwischen unterschiedlichen Systemen, der entfernte Funktionsaufruf ist dennoch allgegenwärtig.

Wie bei RPC ist die Cliententwicklung einfach und eindeutig, allerdings abhängig von der Serverentwicklung. Je umfangreicher, feingranularer und somit aufwändiger die Schnittstelle auf Serverseite implementiert ist, desto vielfältiger sind die Datenstrukturen, die dem Client zur Verfügung stehen.

Der Schnittstellenkontrakt regelt dabei, welche Daten in welchem Detailgrad auf welche Art ausgetauscht werden können und was die Daten bedeuten. Mit "Kein Kontakt ohne Kontrakt!" lässt sich deshalb das allgemeine Vorgehen beschreiben. Sowohl der Client als auch der Server können sich auf den Schnittstellenkontrakt verlassen. Änderungen sind nur erlaubt, wenn der Schnittstellenkontrakt zuvor entsprechend angepasst wurde. Diese Eineindeutigkeit ist grundsätzlich gut. Sie bedeutet aber auch: Sollte der Client aufgrund veränderter Data Access Pattern anders strukturierte und detaillierte Daten benötigen, müssen Entwickler vor der Clientimplementierung erst den Schnittstellenkontrakt festlegen und danach die entsprechende Schnittstelle auf Serverseite implementieren.

Aufgrund des Einsatzes von XML ist SOAP über die Maßen geschwätzig. Eine SOAP-Nachricht besteht immer aus einem Umschlag, der bestimmte Mindestinformationen verlangt. Im Umschlag verpackt ist dann die eigentliche Nutzlast aus Funktionsname, Parametern und Daten, wiederum in XML-Notation. Diese kann mitunter langatmig und unverhältnismäßig ausfallen, etwa durch lange Bezeichner. Das führt dazu, dass für den Abruf von wenigen Byte fachlicher Daten mehrere Hundert Byte technischer Overhead entstehen. Allein dadurch ist SOAP für den Einsatz über Mobilfunknetze und andere Kommunikationswege mit geringer Bandbreite ungeeignet. Ferner gilt auch für SOAP: Pull statt Push.

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Header>
  <ebl:RequesterCredentials soapenv:mustUnderstand="0" xmlns:ebl="urn:ebay:apis:eBLBaseComponents">
   <ebl:eBayAuthToken xmlns:ebl="urn:ebay:apis:eBLBaseComponents">token</ebl:eBayAuthToken>
  </ebl:RequesterCredentials>
 </soapenv:Header>
 <soapenv:Body>
  <GeteBayOfficialTimeRequest xmlns="urn:ebay:apis:eBLBaseComponents">
   <DetailLevel>ReturnAll</DetailLevel>
   <Version>423</Version>
  </GeteBayOfficialTimeRequest>
 </soapenv:Body>
</soapenv:Envelope>

(SOAP-Beispiel: Aus der offiziellen Dokumentation der eBay-Verkaufs-API stammt diese SOAP-Nachricht. Ziel der Nachricht ist der Abruf der offiziellen eBay-Zeit.)

REST, der Missverstandene

Wie eine Art Gegenentwurf zu SOAP stellt sich das mittlerweile überall anzutreffende REST dar – oder um genau zu sein der Architekturstil Represesentational State Transfer. Dieser Architekturstil legt unter anderem eine über alle Anwendungen hinweg einheitliche, ressourcenorientierte Schnittstelle zum Zugriff auf Daten fest.

Das Datenformat für den Datenaustausch darf der Client frei wählen, ebenso den Transportweg, auch wenn meist JSON und XML über HTTP zum Einsatz kommen. Weil HTTP gut standardisiert ist, vermeidet man bei REST üblicherweise Schnittstellenkontrakte. Die Adressierung der Ressourcen erfolgt per allseits geläufigem Uniform Resource Identifier (kurz URI). Wegen dieser Vorzüge lässt sich REST intuitiv und schnell implementieren, was einen Code-First-Ansatz fördert. Entwickler sind also in der Lage, kurzfristig zusätzliche Ressourcen bereitzustellen. Stark variierende Data Access Pattern kann REST auf diese Weise nicht direkt bedienen, aber die Cliententwicklung wird auch nur geringfügig verzögert.

Genau wie SOAP kann REST allerdings geschwätzig sein. Schließlich sind die Struktur der Daten und die Beziehungen der Datenfelder zueinander starr. Aufrufparameter ermöglichen in der Regel nur eine Reduzierung der Informationen, etwa durch Suche, Filterung, Sortierung, Paginierung oder Ausschluss von Feldern. Neue Aggregate lassen sich erst nach dem Datenabruf aufbauen. Das bedeutet: Ein Client muss unter Umständen viele Ressourcen mit teilweise irrelevanten Details nacheinander abrufen, um daraus die für ihn passende Auswahl an Daten zu einer neuen Struktur zusammenstellen zu können. Dieser Overhead an fachlichen Daten kann mitunter gravierend ausfallen und ist im Umfeld geringer Bandbreiten und hoher Latenzen für Echtzeitanwendungen nicht tragbar.

Ein vermeintlicher Vorteil von REST ist gleichzeitig auch ein Nachteil. Denn REST ist eher unterspezifiziert. Die Art und Weise der Umsetzung ist nämlich nicht weiter vorgeschrieben, sodass jeder die Implementierungsstrategie frei wählen darf, etwa für Error-Handling, Authentifizierung oder Datenrepräsentation. Das wirkt im ersten Moment zwar praktisch, wird aber spätestens dann zur Last, sobald diese Spezifikationsarbeit zur Implementierungszeit nachgeholt werden muss. Damit ist REST schlussendlich eine eher schlechte Schnittstelle für Interoperabilität. Zumal die als REST definierten Schnittstellen oftmals nur das Prädikat REST-like tragen, weil sie die Selbstbeschreibung der Schnittstelle, die HATEOAS bieten könnte, im Kontext betrieblicher Informationssystem gar nicht benötigen. Pull statt Push gilt wiederum auch bei REST.