Was AJAX-Entwickler schon immer über Web Services wissen sollten

AJAX-Clients kommunizieren mit dem Server auf der Basis von Web-Services-Protokollen. Dabei werden verschiedene auf http basierende Formate wie z.B. REST, JSON und SOAP verwendet. Hier finden Sie einen Überblick über die wichtigsten Protokolle und Ihre Eigenschaften und erfahren für welchen Einsatzzweck sie sich am besten eignen.

Web Services ist ein Sammelbegriff für Operationen die über Netzwerke aufgerufen werden können. Da er Ende des Jahres 2000 im Zusammenhang mit dem SOAP Protokoll geprägt wurde wird er häufig auch mit SOAP gleichgesetzt obwohl es einige zum Teil deutlich ältere Protokolle und Verfahren für "Operationen die über Netzwerke aufgerufen werden können" gibt.

Wer klassische Web Anwendungen implementiert kümmert sich normalerweise nicht sehr für die Daten die tatsächlich über die Netzwerkverbindung übertragen werden. Interessant sind vor allem die Nutzdaten, typischerweise HTML Tags, die Cookies und die Meta-Informationen die z.B. zur Steuerung des Caches auf dem Client verwendet werden.

Insbesondere das <form> HTML Element bringt einiges an Funktionalität mit sich. Auch hier wird weit oberhalb der Protokollebene implementiert indem <input> Elemente mit all ihren möglichen Optionen verwendet werden um Daten an den Server zurücksenden.

Die HTML Funktionalität die in den Browsern heute zur Verfügung steht sieht außer dem Laden einer Seite und evtl. dem Nachladen von dynamisch hinzugefügten Elementen keine weitere Interaktion mit dem Server vor, Web Services die nicht dazu führt, dass die Seite komplett neu aufgebaut wird.

Mit AJAX ändert sich an dieser Situation einiges, und deshalb lohnt sich ein Blick auf die Protokollebene die über das XMLHttpRequest Objekt verfügbar wird. Durch ein besseres Verständnis erreicht man auch eine höhere Sicherheit bei der Bewertung der möglichen Implementierungen und der notwendigen Architektur.

Microsoft hat 1999 mit dem ActiveX-Control das unter dem Namen "Microsoft.XMLHTTP" ab dem IE 5.0 verfügbar wurde hier eine zusätzliche Möglichkeit geschaffen mit der es möglich ist auf der tiefer liegenden Ebene des http Protokolls eine weitere Verbindung zum Server aufzubauen. Glücklicherweise wurde diese Idee, die auch von anderen Browsern aufgenommen und umgesetzt, denn die dadurch entstehenden Möglichkeiten sind zu fantastisch als dass man sie wegen irgendwelcher Prinzipien oder Weltanschauungen (Kennen Sie "browser wars" ?) nicht umsetzten sollte.

Inzwischen ist aus den existierenden sehr kompatiblen Implementierungen des XMLHttpRequest Objektes ein Standard entstanden, siehe http://www.w3.org/TR/XMLHttpRequest/.

Das http(s) Protokoll

Das http Protokoll ist die Grundlage der Kommunikation in AJAX Anwendungen. Wenn mit dem XMLHttpRequest Objekt kommuniziert wird, werden (der Name des Objektes deutet es bereits an) müssen die speziellen Eigenschaften und Vorgehensweisen dieses Protokolls berücksichtigt werden. Die weiteren Protokolle wie z.B. REST basieren darauf und nutzen die im http Protokoll definierten Möglichkeiten.

Der Mechanismus des http Protokolls ist recht einfach indem Texte und Nutzdaten über einen TCP/IP Port ausgetauscht werden. Das trifft auch auf binäre Dateien wie z.B. GIF Dateien zu.

Jeder Nachrichtenaustausch besteht aus einem Header der mit flexibel um Angaben erweitert werden kann und aus einem optionalen Body für die Nutzdaten. Initiiert wird eine http Übertragung immer vom Client, in unserem Fall dem Browser, und Server antwortet über die gleiche Verbindung.

Die übermittelten unsichtbaren Zeichen am Zeilenende sind hier in spitzen Klammern hinzugefügt denn sie spielen für die Auftrennung der Bestandteile der Übertragung eine wesentliche Rolle.

Jede Übertragung zum Server, wie auch die im Listing 1, wird durch eine Methode, der URL und der Angabe des Protokolls in der ersten Zeile eingeleitet. Mit der Methode wird angegeben was mit der durch die URL definierte, angeforderte Ressource zu geschehen hat.

Im Beispiel wurde die GET Methode verwendet, die prinzipiell keine weiteren Nutzdaten verwendet sondern für die Abfrage von meist statischen Daten verwendet wird, die unter einer URL verfügbar sind. Typische Beispiele sind HTML Dateien, Grafiken oder referenzierte JavaScript Dateien.

Nach der obligatorischen Leerzeile die den Header abschließt können Nutzdaten folgen, die an den Server übermittelt werden. Die typische Situation dafür ist das Absenden eines ausgefüllten HTML Formulars mit der POST Methode.

Der ersten Zeile folgen die Header Informationen in der Form von Merkmal und Wert Paaren wie z.B. die optionale Zeile mit der Angabe der Länge der Nutzdaten und dem übermittelten Datentyp der Nutzdaten.

Die Antwort vom Server ist ebenfalls Text und weist eine hohe Ähnlichkeit zu einer Abfrage aus. In der ersten Zeile wird die Qualität der Antwort als Statuscode zurückgeben. Die "200 OK" steht dabei für eine fehlerfreie vollständige Übertragung. Dann folgen wieder einige Headerzeilen in denen typischerweise auch die Länge der Nutzdaten beschrieben ist, die unmittelbar nach der Leerzeile beginnen. Bilder werden ab diesem Punkt binär übertragen.

Eine weitere grundlegende Eigenschaft dieses Protokolls ist die zustandslose Art der Anfrage an einen Server. Das Protokoll kennt keine Querverweise zu anderen Abfragen oder benötigt irgendwelche Informationen über den Client auf der Seite des Servers. Die Abfragen selbst beschreiben sich immer vollständig.

Bei der Verwendung des XMLHttpRequest Objektes zur Kommunikation ist die Angabe der Methode zwingend notwendig. In vielen Fällen muss auch der Datentyp der zu übertragenden Daten gesetzt werden.

Mit der Variante des https Protokolls, das die gleichen Daten wie das http Protokoll austauscht, existiert auch die Möglichkeit diese Übertragung zu verschlüsseln. Die Details dieser Verschlüsselung und der typische Verlauf der zum Austausch der notwendigen Zertifikate benötigt wird, wird einem glücklicherweise vollständig vom XMLHttpRequest Objekt abgenommen.

Tipp: Beobachten kann man diese Übertragungsdetails z.B. mit dem kostenlosen Werkzeug Fiddler für Windows, der unter http://www.fiddlertool.com verfügbar ist. Fiddler richtet sich als http Proxy im System ein und protokolliert alle Datenübertragungen mit.

Cross-Site Scripting (XSS)

Unter Cross-Site Scripting versteht man den Zugriff einer Web Applikation von einem Server auf die Daten einer anderen Web Applikation auf einem anderen Server. Zugriffe dieser Art wurden in der Vergangenheit oft für DoS Attacken und Security Leaks ausgenutzt.

Die Einschränkung des XMLHttpObjekts besteht darin, dass eine Kommunikation von einer geladenen Seite aus nur bei Verwendung des gleichen Protokolls und zum gleichen Server möglich ist.

Einem Anwender sollte anhand der Adressleiste des Browser erkennen können mit welchem Server er aktuell kommuniziert. Diese in Zeiten des Phishings nachvollziehbare Anforderung wird allerdings bei der Anzeige von Bildern und dem Nachladen von Scripten nicht ganz eingehalten. Unterschiedliche Protokolle werden ggf. dem Benutzer als Meldung angezeigt und Ressourcen anderer Server werden gerne ausgefiltert um z.B. Werbung zu unterbinden.

Tipp: Wenn Sie eine AJAX Anwendung konzipieren, dann verlassen Sie sich nicht darauf, dass Sie auf Ressourcen anderer Server direkt zugreifen können.

Die Chance: Eine Applikation auf einem Server kann keine AJAX Applikation auf Clients ausrollen die eine Denial Of Service (DOS) Situation auf einem anderen Server zur Folge hat. Jede AJAX Anwendung muss deshalb auf dem zugehörigen Server ein Gateway auf die Ressourcen des anderen Servers implementieren. Dies ermöglicht gleichzeitig das Caching und die Konsolidierung der Daten von anderen Servern auf dem Server der AJAX Anwendung.

Siehe auch http://httpd.apache.org/info/css-security/

Mit Sicherheit

Obwohl bei AJAX Anwendungen eine weitere Art der Kommunikation zwischen Client und Server dazukommt ist das Sicherheitsmodell im Prinzip unverändert. So verwendet das XMLHttpObjekt offensichtlich den selben http Protokoll Stack der auch beim Aufbau der Seite verwendet wird und übermittelt z.B. automatisch Cookies und Referrer und der Server kann so z.B. die Client-Session einer AJAX Abfrage zuordnen.

Trotzdem gilt generell bei Abfragen vom Server und bei dem Übermitteln von Daten an den Server nicht vertraut werden kann. Diese Annahme muss auch für alle Daten gelten, die über die AJAX Kommunikation übermittelt werden. Die typischen Security Themen wie z.B. SQLInjection, JavaScriptInjection, Cross Side Scripting und Buffer Overflows in den verwendeten Libraries sind auch bei der AJAX Kommunikation zu beachten.

Was den IE 5.x bis 6.0 betrifft wird leider das XMLHttpRequest Objekt als ActiveX Komponente aktiviert. Wer den Schalter für die Aktivierung von "Sicheren" ActiveX Komponenten ausgestellt hat kann somit AJAX Anwendungen nicht verwenden. Mit dem IE 7.0 wird das XMLHttpRequest entsprechend dem Standard auch als direktes Objekt zur Verfügung stehen und kann unabhängig vom ActiveX Mechanismus berechtigt werden.

Das Protokoll der http <form> Elemente

Innerhalb der Nutzdaten des http Protokolls gibt es seit Einführung des <form> Elementes in HTML einige weitere Festlegungen wie Daten der <input> Elemente einer Form zu übertragen sind. Eine wichtige Rolle spielt dabei das Protokoll mit dem Typ "application/x-www-form-urlencoded”. In Listing 2 kann man erkennen dass innerhalb der Nutzdaten die "&" und "=" Zeichen als Trennzeichen von Namen-Werte Paaren verwendet werden, so wie dies auch in URLs im Anschluss an ein Fragezeichen oft zu sehen ist.

Die andere Protokollspezifikation mit dem Typ "multipart/form-data” wird ebenfalls von allen Browsern und Servern verstanden und ermöglich ein Upload von umfangreichen Dateien an einen Server. Dieses Protokoll muss verwendet werden wenn ein <input type=”file”> Element verwendet wird.

Für AJAX spielt dieses Protokoll eine große Rolle, denn einige Frameworks verwenden dieses Protokoll, insbesondere "application/x-www-form-urlencoded” um die reguläre Arbeitsweise eines <form> Elementes zu simulieren. Die Daten werden auf dem Client mit der Hilfe von JavaScript Funktionen zusammengesetzt und mit einem XMLHttpRequest Objekt an den Server übertragen. Dieser reagiert so, als ob das Formular abgesendet wurde und übermittelt eine neue Seite an den Client. Der Client kann die relevanten Stellen aus dem zurückgegebenen HTML Code ausschneiden und in die aktuelle Seite integrieren. Damit werden selektiv einige Teile der Seite aktualisiert.

Diese Art der AJAX Programmierung wird oft als indirekte AJAX Frameworks bezeichnet. Eine recht vollständige Liste und interessante Vergleiche von .NET basierten AJAX Frameworks die dieses Verfahren nutzen findet man unter http://www.daniel-zeiss.de/AJAXComparison/Results.htm.

Der Vorteil dieses Protokolls liegt darin, dass die Web Server damit bereits umgehen und die Nutzdaten entsprechend aufbereiten können. Wichtig bei der Verwendung des XMLHttpRequest Objektes ist, dass der HTTP-Header "Content-Type" korrekt gesetzt wird.

Das REST Verfahren

Der Begriff REST wurde von Roy Thomas Fielding (http://www.ics.uci.edu/~fielding/), in seiner Dissertation geprägt und steht für REpresentational State Transfer. Eine feste Protokolldefinition gibt es nicht sondern mit REST wird der Ablauf eines Server Aufrufs bezeichnet, wenn man Daten von einem Server holt indem man eine bestimmte Adresse (URL, ggf Parameter) befragt um die dort liegenden (XML-) Daten zu holen.

In der Tat ist das http Protokoll an sich eine einfache Umsetzung dieses Prinzips. Es kann sinnvoll für Datenquellen verwendet werden, die sich nicht sehr häufig ändern wie z. B. RSS feeds. Hier wird die Information oft in eine statische Datei geschrieben wenn ein neuer Artikel publiziert wird. Natürlich ist es heutzutage nicht nur denkbar auf statische Inhalte zuzugreifen sondern man kann die Ergebnisse auch dynamisch errechnen.

Um mit einem REST Verfahren auch Änderungen an den Ressourcen auf dem Web zu ermöglichen haben sich bei http einige weitere Methoden wie PUT und DELETE etabliert.

WebDAV

Eine Erweiterung des http Protokolls unter der Verwendung von XML ist das Beispiel WebDAV. Mit diesem Protokoll können Dateien oder andere Ressourcen auf dem Web verwaltet, geändert und geordnet werden. Es ist besonders erwähnenswert, da Outlook Web Access von Microsoft, eine der ersten AJAX Anwendungen die um das Jahr 2000 entstand, mit diesem Protokoll arbeitet und sicherlich dafür gesorgt hat, dass das XMLHTTP ActiveX Control brauchbar und robust implementiert wurde.

HTML

Bei Web Anwendungen liegt es nahe HTML Fragmente der aktuell geladenen Seite, die sich durch eine AJAX Aktivität verändern in der Form von HTML Fragmenten zu übermitteln. Diese werden auf dem Client wieder in die aktuelle Seite eingebaut ohne dass die Seite neu geladen werden muss.

Die Übertragung spart in erheblichem Maße Bandbreite auf dem Netzwerk aber auch das Nachladen von Bildern und verknüpften JavaScript oder CSS Dateien entfällt.

Dies ist das gängige Verfahren von indirekten AJAX Frameworks. Das ASP.NET Atlas Framework von Microsoft ermöglicht anhand eines serverseitigen <atlas:updatepanel> Elementes die dynamischen Bereiche einer Seite und die Events beim Update zu beschreiben.

Listing 5: indirekte AJAX Programmierung durch Spezifikation von dynamischen Bereichen.

Diese Lösungsansätze haben den Charme dass wenig JavaScript Kenntnisse beim Programmierer der einzelnen Seiten benötigt werden.

"Text only"

Die Übermittlung der Daten eines Web Services in der Form ihrer textuellen Repräsentation ist sicher die einfachste und dazu sehr effiziente Art wenn es um Zeichenketten oder auch einfache Zahlen geht. Allerdings stößt man schnell an die Grenzen der Komplexität bei komplexeren Datentypen. Es ist zu klären wie z.B. ein Datum oder eine Liste übertragen wird. Das Beispiel der Primfaktoren macht dies bereits deutlich denn Listen von Zahlen werden gerne auch mit Komma oder Semikolon getrennt.

Einfache AJAX Beispiele verwenden gerne diesen Ansatz. Man muss sich früh entscheiden, ob man selbst ein Datenformat mit allen Details spezifizieren will oder ob es sinnvoller ist auf ein standardisiertes und verbreitetes Format auszuweichen.

JSON

JSON steht für JavaScript Objekt Notation und ist ein Bestandteil der JavaScript Spezifikation ECMA-262. Mit Hilfe dieser Syntax ist es möglich eine statische Beschreibung von komplexen Objekten vorzunehmen. Diese Syntax kann im Browser effizient genutzt werden da das im Browser vorhandele JavaScript einen String mit dieser Syntax durch einen einfachen Aufruf der eval Funktion in ein JavaScript Objekt umsetzen kann. Auf der Seite des Servers, der solche Objektbeschreibungen zusammensetzen muss, sind aufgrund der Verbreitung vermutlich bereits geeignete Klassen oder Bibliotheken vorhanden. Die WebSite http://json.org/ gibt hierzu einen recht guten Überblick

Der Nachteil dieser Objektbeschreibung liegt darin, dass es keinen standardisierten Weg gibt um JSON Syntax aus JavaScript Objekten zu erzeugen und um visualisierbare HTML Objekte aus JavaScript Objekten abzuleiten.

Wichtig ist dabei auch die Argumentation "eval is evil". In der Tat ist es ein ziemlich unsicherer Ansatz JSON Daten, die vom Web kommen einfach über die Funktion eval() auszuführen. Das Ergebnis kann ein brauchbares Objekt sein. Es kann aber auch irgendein Code dadurch ausgeführt werden, der dann auf dem Client "bösartig" um sich schlägt. Aus diesem Grund gibt es auch spezielle und "sicherere" JSON Interpreter für JavaScript.

Ein wichtiger Grund für die Verwendung von JSON ist, dass es gegenüber XML Bandbreite spart (etwa 40%) und bei einfachen Daten gewöhnlich im Client schneller ist, weil kein XML-Objekt erzeugt und geparst werden muss.

XML

Die Übertragung von Daten in einer XML Notation ist die echte Alternative zur Übertragung von Daten in JSON.

Mit der Verwendung von XML sind die Probleme der Notation von Datentypen und komplexen Objekten gelöst und es ist nicht notwendig eigene Konventionen zu definieren. Anstatt sich an JavaScript zu orientieren ist hierbei eine größere Nähe zu (X)HTML zu erkennen.

Inzwischen wird dieses Format von allen gängigen Browsern ebenfalls durch XML Objekte unterstützt und das XMLHttpRequest Objekt ermöglicht es, dass Antworten vom Server in XML Syntax direkt als XML Dokument zur Verfügung stehen.

XML Dokumente sind bei großen Objekten deutlich performanter als JSON Objekte und in den Browsern steht ein XSLT Mechanismus zur Verfügung der eine sehr effiziente Verarbeitung von XML Daten und eine Umsetzung in HTML ermöglicht.

SOAP

Mit der SOAP (Simple Object Access Protocol) Spezifikation wurde 1999 ein auf XML basierender Standard definiert der heutzutage eine erstaunliche Unterstützung und einen enormen Funktionszuwachs von verschiedenen Plattformen und Herstellern bekommt. Aus den Anfängen ist das Statement von Dave Wine, einem der SOAP Väter bekannt:

The purpose of both specs [SOAP and XML-RPC] is to enable scripted web applications to cross operating system boundaries"

Das ist auch eine Umschreibung für die Architektur die heute unter AJAX bekannt ist. In der einfachsten Form besteht SOAP aus einem standardisierten XML Dokument, das über http oder https von einem Client an einen Server übertragen wird und vom Server mit einer Antwort quittiert wird. Das Protokoll folgt damit genau dem Ansatz der auch mit dem XMLHttpRequest Objekt realisiert werden. kann.

Die gegenüber der Übertragung von reinem Text oder JSON Ausdrücken erhöhte Komplexität von SOAP kommt primär davon, dass das Protokoll von Anfang an so aufgesetzt wurde, dass es problemlos erweiterbar ist. Das ermöglicht die zusätzliche Integration von Mechanismen wie z.B. Signaturen oder Routing Information.

SOAP ist als Protokoll für eine Client-Server Kommunikation im Web deswegen besonders geeignet, weil von Anfang an eine dem Web ähnliche Art der Datenübertragung vorgesehen wurde. Es kann exakt der Port des WebServers verwendet werden der auch für die Abfrage von normalen Seiten und Grafiken verwendet werden kann und das http Protokoll war die erste spezifizierte Übertragungsmethode. Eine Implementierung eines SOAP Clients existiert für den Microsoft Internet Explorer bereits seit ca. 1999 in der Form eines Behaviours.

Inzwischen existieren für alle Server Plattformen entsprechende SOAP Implementierungen so dass hier von einem echten Cross-Plattform Standard gesprochen werden kann.

SOAP Nachrichten können im Browser erzeugt und verarbeitet werden. Auf dem Internet gibt es einige low-level Beispiele die aufzeigen wie XML zusammengesetzt werden kann um ein entsprechendes XML Dokument zu erhalten. Wesentlich interessanter ist es aber, dass passend zu SOAP auch WSDL (Web Service Description Language) existiert, eine standardisierte Spezifikation der für einen SOAP Aufruf notwendigen XML Daten. Anhand dieser XML basierten Definition ist es in den Hochsprachen möglich Proxy Klassen zu erzeugen und diese in die Implementierung der Kommunikationspartner einzubinden.

Dieser Mechanismus kann auch in JavaScript Applikationen angewendet werden. Das Behaviour für den IE von Microsoft, das unter http://msdn.microsoft.com/workshop/author/webservice/overview.asp verfügbar ist lädt zur Laufzeit eine WSDL vom Server und generiert entsprechende JavaScript Objekte um die Funktionen des Servers aufzurufen.

Die Implementierung, die in http://www.mathertel.de/AJAXEngine und anderen AJAX Frameworks verwendet wird, generiert JavaScript Code bereits auf dem Server und funktioniert auch für Mozilla/Firefox und den Safari Browser.

Ein Plädoyer für SOAP Web Services in AJAX Applikationen

Um AJAX Anwendungen zu realisieren muss sowohl auf dem Server als auch auf dem Client der notwendige Code zum Austausch von asynchronen Nachrichten implementiert werden. Web Server Plattformen, die bereits einen SOAP Server als Bestandteil anbieten stellen damit bereits schon alle Funktionalitäten standardisiert zur Verfügung. Der Aufwand der Implementierung eines serverseitigen Frameworks entfällt damit komplett – es muss natürlich die Funktionalität der Anwendung realisiert werden.

Daneben ist es bereits mehrfach vorgekommen, dass gerade durch die neue Realisierung von AJAX fähigen Services eine Sicherheitslücke im Server aufgemacht wurde. Dass Buffer Overflow in Standard SOAP Servern von Microsoft oder Sun zu Problemen führen ist dagegen eher gering, denn der Aufmerksamkeitswert auf diese Server ist aktuell sehr hoch.

Alle diese Gründe zeigen auf, dass der anfängliche Mehraufwand bei der Implementierung eines SOAP Clients zur direkten Kommunikation mit Web Services gerechtfertigt ist.

Zum Schluss

Die Entscheidung "selber machen" oder "kaufen" bzw. "standardisiertes Protokoll" oder "eigenes Protokoll" muss jeder für sich selbst treffen. Die Protokollebene liefert aber einige Aspekte für eine fundierte Entscheidung. Ein Verständnis, was da tatsächlich auf dem http Kanal übertragen wird ist in jedem Fall hilfreich und spätestens bei der Fehleranalyse unabdingbar.