Content Analysis Standards development Heterogeneity MEtadata REtrieval Newsletters
   
Latest Newsletter
12.08.2005
XPath & XQuery
XPath & XQuery

Newsletter Discussion


Abstract

REST is an architectural style for building large-scale networked applications. It is a description of the features of the WWW that made the Web so successful. REST describes a networked system in terms of data elements (resource, resource identifier, representation), connectors (client, server, cache, resolver, tunnel) and components (origin server, gateway, proxy, user agent).

Eine Darstellung von REST

Anmerkungen zu Paul Prescod

Was ist REST ?

Es nennt sich Representational State Transfer und es wendet größtenteils die Prinzipien des Word Wide Web für transaktionsorientierte Dienste und weniger für veröffentlichungsorientierte Websites an. Wenn wir diese Strategien in der realen Welt anwenden, tun wir dies, in dem wir Web-Technologien wie z.B. URIs, HTTP und XML benutzen. Im Gegensatz zur derzeitigen Generation von Web Service Technologien machen wir diese Technologien zum zentralen Gegenstand, wir überdenken unsere Web Service Schnittstelle unter dem Blickwinkel von URIs, HTTP und XML. Dieses Überdenken ist es, was unsere Web Services über die Fähigkeiten der Technologien der ersten Generation hinausragen lässt, welche auf Remote Procedure Call APIs wie z.B. SOAP-RPC basieren.

REST ist eine bestimmte Art und Weise, große vernetzte Applikationen zu konstruieren. Es ist eine Beschreibung der WWW-Eigenschaften, welche das Web so erfolgreich machen.

REST beschreibt ein vernetztes System in Bezug auf:

  • Datenelemente (Ressource, Ressourcenbezeichner, Repräsentation)
  • Verbindungsstellen = Connectors(Client, Server, Cache, Resolver, Tunnel)
  • Komponenten = Components(Ursprungsserver, Gateway, Proxy, User Agent)

Relevante Eigenschaften von REST

Auf Datenelemente wird durch ein standardisiertes Interface zugegriffen. Komponenten kommunizieren durch den Transfer von Ressourcenrepräsentationen über dieses Interface, sie arbeiten also nicht direkt mit den Ressourcen selbst. Verbindungsstellen stellen ein abstraktes Interface für die Komponentenkommunkation dar, wobei die Implementierungsdetails der Kommunikationsmechanismen verborgen bleiben. Die Komponenten nutzen die Verbindungsstellen, um Zugriff auf Ressourcen zu haben, um Zugriff auf diese bereit zu stellen oder den Zugriff zu vermitteln. Alle Anfragen an die Komponenten müssen die vollständigen Informationen beinhalten, die für das Verstehen der Anfragen nötig sind, ohne dass auf vorhergegangene Anfragen zurückgegriffen werden muss, d.h. sie sind zustandslos. Es ist wichtig, dass die Vermittler (Components und Connectors) ausdrücklicher Teil der Architektur sind. Durch die REST-Charakteristiken können diese Vermittler mehr sein als "dumme Router", nämlich aktive Teilnehmer.

Da REST nur die wesentlichen Elemente des WWW benötigt, ist es nicht überraschend, dass das Protokoll, welches die meisten der oben genannten Eigenschaften aufweist, HTTP ist. REST und HTTP sind jedoch unterschiedliche Konzepte, es ist aber möglich REST Konzepte vollständig in anderen Protokollen und Systemen anzuwenden.

Da die meisten Leute den unmittelbaren Wert von Komponenten und Verbindungsstellen kennen, hat sich die Diskussion weitestgehend auf den Aspekt der Informationsstruktur von REST konzentriert - Ressourcen, Repräsentationen, URIs, standardisierte Interfaces etc. Dieser Bereich wird informell als "Ressourcen Modellierung" bezeichnet. Die meisten Beispiele sind in HTTP-Mitteilungen und in URI-benannten Ressourcen gefasst. Theoretisch sollen viele komplexe Systeme mit reinem HTTP vollkommen beschrieben und implementiert werden.

Ein kurzer Rückblick

REST ist ein Modell für verteilte Datenverarbeitung. Es wird in der weltweit größten Anwendung verteilter Datenverarbeitung benutzt, nämlich dem World Wide Web. Wenn es auf Web-Service Technologien angewandt wird, beruht es gewöhnlich auf einem Technologietrio, dessen Teile als extrem erweiterungsfähig konstruiert wurden: XML, URIs und HTTP. Die Erweiterungsfähigkeit von XML sollte für die meisten offensichtlich sein, während dies für die anderen beiden vielleicht nicht der Fall ist.

URIs sind ebenfalls erweiterungsfähig: es gibt eine unendliche Anzahl möglicher URIs. Noch wichtiger ist jedoch, dass sie auf eine unendliche Anzahl von logischen Objekten, also Ressourcen, angewandt werden können. URIs sind lediglich die Namen und Adressen der Ressourcen. Einige der REST-Befürworter nennen den Prozess des Einbringens der Applikation in dieses Modell "Resourcen Modellierung". Dieser Prozess ist noch nicht so formal wie die objektorientierte Modellierung oder die Entity--Relation Modellierung, aber er ist diesen ähnlich.

Die Beständigkeit und Flexibilität von REST beruht auf der überall vorhandenen Nutzung von URIs. Dieser Punkt kann nicht oft genug betont werden. Als das WWW erfunden wurde, hatte es drei Komponenten: HTML, welches wohl die schlechteste Auszeichungssprache ihrer Zeit war (außer dass sie einfach war), HTTP, welches das primitivste Protokoll seiner Zeit war (außer dass es ebenfalls einfach war) und URIs (damals URLs genannt), welche der einzige generalisierte und universelle namens- und adressgebende Mechanismus im Internet war. Wieso hat das World Wide Web Erfolg gehabt? Nicht aufgrund von HTML oder HTTP. Diese Standards waren lediglich Hüllen für URIs.

Grenzen von REST

Es gibt nichts umsonst; REST ist kein Wundermittel. Das größte Problem, welches wohl die meisten mit REST haben, ist, dass sie ihr Problem neu überdenken müssen und zwar im Hinblick auf die Manipulation von adressierbaren Ressourcen anstelle von Methodenaufrufen an die Komponenten. Natürlich kann man REST auf der Server-Seite implementieren wie man will. Aber die API, die man dem Client übermittelt, sollte in Form von HTTP-Manipulationen von XML Dokumenten, die von URIs adressiert werden, erfolgen, nicht in Form von Methodenaufrufen mit Parametern.

Kunden mögen ein auf Komponenten basierendes Interface einem REST-Interface vorziehen. Programmierer sind es eher gewohnt, APIs zu benutzen und APIs können besser in bereits existierende Programmiersprachen integriert werden. Für Programmierer auf der Client-Seite ist REST eine gewisse Abweichung vom Gewohnten, während es für Programmierer auf der Server-Seite nicht viel anders ist, als das, was sie seit Jahren praktizieren, nämlich Webseiten erstellen.

REST führt eine Art des Programmierens ein, die viele URIs aber wenig Methoden beinhaltet. RPC gibt einem die Möglichkeit eine Anwendung nach eigenem Belieben zu strukturieren. Wenn ein bestimmtes Problem mit RPC behoben werden kann und zukünftige Erweiterungsfähigkeit und Sicherheit nicht von großer Bedeutung sind, sollte man sicherlich den freieren Ansatz wählen.

Das Beste über REST

Der beste Teil von REST besteht allerdings darin, dass es vom Warten auf Standards wie z.B. SOAP und WSDL befreit. Man benötigt sie nicht. Man kann REST heute verwenden, in dem man W3C und IETF Standards benutzt, welche zwischen 10 Jahren (URIs) und 3 Jahren (HTTP 1.1) alt sind.

Ob man bereits heute oder erst in zwei Jahren anfängt mit partner-orientierten Webservices zu arbeiten, der schwierige Teil wird es sein, die eigenen Geschäftsdokumente und -prozesse mit denen des Partners abzugleichen. Die Technologie, die benutzt wird, um Bits von einem Ort zum anderen zu verschieben, ist nicht von Bedeutung, vielmehr ist es die Modellierung von geschäftsspezifischen Dokumenten und Prozessen.

REST ist kein Patentrezept für die Integration von Geschäftsprozessen. Es bringt lediglich eine gewisse Freiheit von der Tyrannei urheberrechtlich geschützter Adressierungsmodelle, die in RPC-Parametern verborgen sind. Man sollte nicht davor scheuen, Hyperlinks und URI-Adressen in seinen Geschäftsdokumenten und -prozessen zu benutzen. Spezifikationen wie SOAP und WSDL könnten dies beinah unmöglich machen, aber das ist ein Problem dieser Spezifikationen, nicht eines, was mit dem Verständnis eines Problems zu tun hat. Wenn man Hyperlinks in der Modellierung von geschäftlichen Dokumenten und Prozessen benutzt, dann gibt es ein Protokoll, welches einem keine Steine in den Weg legt: HTTP.

 

Reference

http://webservices.xml.com/

   
Impressum
Cashmere - int RSS Feed
 
Valid XHTML 1.0!
Newsletters
Webmaster