JAXenter.de

Das Portal für Java, Architektur, Cloud & Agile

REST - Der bessere Web Service?

REST - Der bessere Web Service?

Vor nicht all zu langer Zeit schien es völlig klar, dass der Weg für eine interoperable Kommunikation zwischen Anwendungen mit unterschiedlichen Entwicklungszyklen über Web Services führen muss. In letzter Zeit jedoch ist immer häufiger die Rede von einer leichtgewichtigen, einfacheren Alternative: Web Services auf Basis von REST (REpresentational State Transfer).

Die zugrunde liegende Behauptung: Das Web ist gut genug, nur missverstanden. Macht man sich die Mühe, das Kernprotokoll HTTP näher zu betrachten, stellt man fest, dass das Web ohne WSDL, SOAP & Co. keineswegs weniger mächtig, sondern eher mächtiger ist. Mittlerweile ist REST einem ähnlichen Hype unterworfen wie SOAP, WSDL und UDDI vor einigen Jahren. Auch diverse Hersteller, allen voran Sun mit dem JSR 311/JAX-RS sehen in REST zumindest einen wichtigen Teil der zukünftigen Technologielandschaft.

Viele Dienste im Web und viele Applikationen behaupten neuerdings, über ein "REST-Schnittstelle" zu verfügen. Oft verbirgt sich dahinter nur der Verzicht auf einen SOAP Envelope oder ein banales Abbilden von Funktionen auf URLs. Was ist REST denn nun wirklich?

REST: Eine Definition

Der Begriff REST wurde von Roy T. Fielding, einem der Kernentwickler vieler Webstandards und ehemaligem Vorsitzenden der Apache Software Foundation, für seine Dissertation eingeführt. Gemeint ist damit die Architektur, die den Webstandards, insbesondere dem HTTP-Protokoll, zugrunde liegt (theoretisch könnten auch andere Implementierungen dieser Architektur existieren, faktisch ist jedoch nur das Web mit HTTP, URIs usw. relevant). Die wesentlichen Elemente dieser Architektur sind:

• Ressourcen und Repräsentationen
• Hypermedia
• Einheitliche Schnittstelle

Eine Webanwendung ist mit Java-Bordmitteln – z.B. Servlets und dem ab Java 6 mitgelieferten eingebetteten HTTP-Server – leicht erstellt. Damit sie jedoch HTTP so verwendet, wie es dem REST-Architekturstil entspricht, muss sie sich an die Regeln halten, unabhängig davon, ob sie von einem Endanwender per Webbrowser oder von einer anderen Anwendung als Service genutzt wird. Im Folgenden möchte ich Sie davon überzeugen, dass das Ergebnis den Namen "Web Service" sehr viel eher verdient als die WSDL/SOAP-Variante. Denn diese missachtet nahezu alle Grundsätze, die für den Erfolg des WWWs verantwortlich sind.

Ressourcen und Repräsentationen

Ressourcen sind das zentrale Konzept in REST; gelegentlich werden REST-Architekturen daher auch als "ROA" (Resource-oriented Architecture) bezeichnet. Alles, was es aus Sicht des Architekten verdient, eindeutig identifiziert zu werden, ist eine Ressource. Im Web wird für die Identifikation ein anwendungsübergreifend standardisierter, einheitlicher Mechanismus verwendet: Die URI bzw.URL. Generell gilt, dass man lieber zu viele als zu wenige Ressourcen identifizieren sollte. Erste Kandidaten sind die offensichtlichen Entitäten des Domänenmodells: Jede Bestellung, Filiale, Region, jedes Produkt, jeder Artikel kann mit einem eigenen URI identifiziert werden. Auch die "Liste aller Regionen, in denen der Umsatz größer als 5 Mio. Euro war", die "Produkte aus der Kategorie Spielwaren", alle "Bestellungen aus dem Jahr 2008" sind gültige Ressourcen und sollten einen möglichst stabilen und langlebigen URI erhalten.

Was ist der Vorteil eines solchen Entwurfs? Zum einen ist es Möglichkeit, eine solche Ressource mit einem Lesezeichen im Browser zu verknüpfen oder einem Kollegen einen Link darauf schicken zu können. Zum anderen bietet das HTTP-Protokoll ausgefeilte Mechanismen für ein ressourcenbezogenes Caching, sodass in vielen Fällen Netzwerk-Requests vermieden oder minimiert werden können. Schließlich können Ressourcen mit unterschiedlichen URIs mit HTTP-Bordmitteln – z.B. mit einem Webserver oder eine Standardfirewall – feingranular unterschiedlich gegen unerlaubten Zugriff geschützt werden. Ressourcen in REST haben nicht nur eine, sondern potenziell mehrere Repräsentationen. HTTP unterstützt unterschiedliche Repräsentationen derselben Ressource über Content Negotiation (Accept- und Content Type Header). Eine Repräsentation ist eine Darstellung der Ressource, idealerweise in einem Standardformat. Unterschiedliche Klienten können damit jeweils das Format anfordern, das am besten ihren Bedürfnissen entspricht: Ein Browser eine HTML-Darstellung, ein programmatischer Client, vielleicht eine XML- oder JSON-Repräsentation. Auch unterschiedliche Versionen – z.B. die Versionen 1.1 und 1.2 eines XML-Formats für die Darstellung einer Rechnung – lassen sich darüber abbilden.

Im Gegensatz dazu bilden SOAP/WSDL Web Services, aber auch viele Webanwendungen mit einer HTML-Benutzeroberfläche, ihre Funktionalität auf einen einzelnen URI ab. In einer Webanwendung führt das dazu, dass sich die Adresszeile im Browser nie ändert – ein Bookmark oder der Versand eines Links per E-Mail scheidet aus. Aber auch Suchmaschinen wie Google (oder äquivalente interne Dienste oder Appliances) können die in der Anwendung enthaltenen Konzepte nicht mehr erkennen. Bei einer REST-konform entworfenen Anwendung kann die Suchmaschine auf die Ressourcen der Anwendung zugreifen (und zwar nur in dem Maße, wie es die Anwendung zulassen möchte). Die Verwendung einer Web-Service-Schnittstelle dagegen erfordert Spezialkenntnisse bzw. ein genau dafür kodiertes Programm: an solchen Stellen ist das Web "zu Ende". Der SOAP- und WSDL- Begriff "Endpoint" passt hier sehr gut.

 

Kommentare

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).