Bis 2010 entwickelt sich der Architekturstil REST (Representational State Transfer) zum wichtigsten Ansatz für eine serviceorientierte Integration, so die Technologiebewerter von Gartner. Im Gegensatz zu klassischen serviceorientierten Architekturen (SOA) im Backend fokussiert sich REST auf den Desktop.

Flapsig ausgedrückt ist REST eine Serviceorientierung ohne Normierungswut. Der im Jahr 2000 von Roy Fielding â?? einem der Hauptautoren des Protokolls http â?? entwickelte Softwarearchitekturstil setzt auf eine extreme Vereinfachung: â??Weniger ist mehr, einfacher ist besser und das Leichte schlägt das Komplizierte,â?? bringt der Gartner-Analyst David Cearley die drei Basiskonzepte von REST auf den Punkt.

Der Representational State Transfer zielt hauptsächlich auf die flexible Softwarekopplung auf dem Client. Damit unterscheidet sich REST von klassischen SOAs, die ihre Stärke vor allem bei der Integration im Backend ausspielen. Jedoch erfüllt auch REST alle Basisdefinitionen der Serviceorientierung: Die lose Kopplung erfolgt zeitunabhängig, ortsunabhängig und referenzunabhängig.

Seine Stärken entfaltet er Architekturstil laut Cearley vor allem in WEB-2.0-Umgebungen: REST bildet die Grundlage für weborientierte Architekturen (WOA) â?? der Ausweitung von SOA auf den Desktop. Bis zum Ende dieses Jahrzehnts, so schätzt er, wird WOA und damit auch REST zum beherrschenden Integrationsstil in serviceorientierten Umgebungen.

â??Die klassische SOA ist wie ein Puzzle, bei dem die Teile genau aneinander passen müssen. WOA und REST hingegen ähnelnen einem Tangramâ??, erklärt der Gartner-Mann den Unterschied. Wie bei dem alten chinesischen Legespiel. Dadurch könnten die Teile flexibel angeordnet werden. Durch die extreme Reduktion fehlt REST-Anwendungen in der Regel der Kontext, im dem sie ablaufen. SOA-Infrastrukturen setzen für den Nachrichtenaustausch auf branchenspezifische Normen wie XBRL (Extensible Business Reporting Language) im Finanzbereich. REST tut das so nicht, hier wird nur das Protokoll http genutzt. Treten Widersprüche auf, müssen Menschen eingreifen. Integriert etwa eine REST-basierte Oberfläche einer Vertriebslösungen Google Maps, dann muss ein Mitarbeiter unter Umständen aus den geografischen Google-Informationen die benötigten Adressdaten händisch separieren.

Vier grundlegende Vorgaben macht der Architekturstil:

• Die Integration der Anwendungen erfolgt auf Basis des kleinsten gemeinsamen Nenners.

• Es existieren wenige wohldefinierte Operationen, die alle Aufgaben abdecken sollten.

• Die Syntax zur Identifikation von Ressourcen ist universell und eindeutig.

• Das Client-Server-Protokoll ist ebenso zustandslos wie die Serveranwendungen. Dies bedeutet, dass alle auf REST basierenden Applikationen kein Gedächtnis über vorherige Aktionen haben. Alle notwendigen Informationen sind in der Regel in den http-Nachrichten enthalten.

Entsprechend spielt das Webprotokoll die entscheidende Rolle bei REST. Alle Aktionen, die in einer mit diesem Architekturstil realisierten Lösung ausgeführt werden, basieren auf den vier http-Methoden Get, Put, Post und Delete. Mit ihnen wird der Status des Repräsentanten einer Ressource in einen anderen Zustand transferiert â?? daher der Name Representational State Transfer.

Wesentlich bei REST ist, dass nicht mit den Ressourcen wie einer Vertriebsanwendung (CRM) selber gearbeitet wird, sondern nur einem Repräsentanten. Dies ist in der Regel ein eigenständiges HTML-Dokument, über das die Anwendung gesteuert werden kann. Wird dieses Dokument verändert und danach über einen Hyperlink auf ein anderes Dokument gegangen, nennt REST-Autor Fielding das eine Transformation zu einem neuen Status. In einer CRM-Lösung wäre dies beispielsweise die Auswahl eines Kunden, die Aufgabe einer Bestellung und das Anklicken der Bestätigungsschaltfläche.

Mit dem Architekturstil können objektorientierte Lösungen erstellt werden. Hierbei fragt Get die Repräsentation einer Ressource ab, Post fügt ihr etwas hinzu. Put erzeugt neue Ressourcen oder verändert ihren Inhalt, Delete löscht eine Ressource. Im klassischen SOA-Umfeld können dagegen beliebig viele Methoden auf Basis des Protokolls Soap definiert werden.

Bei REST geht die Kommunikation praktisch immer aktiv vom Client aus. Der Server reagiert nur. Er sendet Dokumente auf Anforderung und verarbeitet �nderungen erst nach Bestätigung. Dabei besitzen alle Ressourcen, die von den Repräsentanten dargestellt werden, eine einheitliche Identifikation, die dem W3C-Standard URI (Uniform Resource Identifier) entspricht. In der Regel weisen REST-Anwendungen eine Baumstruktur auf. Repräsentanten können hierbei auf weitere Repräsentanten verweisen.

Quelle: Computer Zeitung 30.03.2007

Eine Einführung in REST mit Beispielen finden Sie hier