JAX07: REST – Das bessere Web-Service Model?…!

REST steht für REpresentational State Transfer. Der Referent (Stefan Tilkov – Blog) meint, dieser komplizierte Name könnte einer der Gründe sein, warum sich REST bis jetzt noch nicht durchgestetzt hat. Dem kann ich nicht unbedingt zustimmen. Je komplizierter die Abkürzung, desto größer ist ja normalerweise der Hype, der um eine Technologie gemacht wird.

REST beschreibt eigentlich einfach nur das HTTP, d.h. HTTP ist eine Implementierung von REST.

Das Prinzip wurde in der Dissertation von Roy Fielding, einem der HTTP-Väter, beschrieben. Man solle sich diese Mal durchlesen, weil sie für eine Dissertation sehr verständlich geschrieben sei.

Die Kernprinzipien von Rest sind folgende:

  • Identifizierbare Ressourcen
    Als Beispiel wäre hier eine URI zu nennen. Ziel ist es durch RESTful Applications, so viele URIs wie möglich zu erzeugen, weil:
    „Jede URI steigert den „Wert“ des Internets“
  • Uniforme Schnittstellte
    Die Interaktion im REST-Modell funktioniert über eine feste Schnittstelle. Eine Beispiel Methode wäre die GET-Funktion von HTTP
  • Ressource-Repräsentationen
    Von einer Ressource kann es verschiedene Repräsentationen geben. Z.B. HTML, PDF, XML, JSON. HTTP unterstützt von Haus aus die bekannten Content Types und das weniger bekannte Content Negotiation! D.h. vor der eigentlichen Datenübertragung kann „ausgehandelt“ werden, welche Repräsentation der Ressource ausgetauscht werden soll.
  • Statuslose Kommunikation
    Einfach ausgedrückt bedeutet das, dass ein Request für sich alleine wiederholbar sein muss. Das heißt nicht, dass die ganze Anwendung stateless sein soll. Das würde natürlich keinen Sinn machen.
  • Hypermedia
    Statusübergänge über Links
    Unterstüzt Evolution von Schnittstellen

REST vs. Web-Services

Eine Unterscheidung zwischen normalen „Web“-Services und RESTful Services kann folgendermaßen vorgenommen werden:
Web-Services haben nur wenig Endpoints, jedes Web-Service-Interface hat jedoch viele Methoden, die nicht uniform sind, sondern sich von Service zu Service unterscheiden. Diese Herangehensweise schafft wenig „Mehrwert“ für das Web, weil nur sehr wenige URIs benötigt werden.
REST hingegen hat eine uniforme Schnittstelle (GET, POST, PUT, DELETE) und viele Enpoints(URIs), weil quasi jeder Datensatz eine eigene URI besitzt (GET customer/id).

Zum Designen einer REST-Applikation solle man nach folgendem Schema vorgehen (http://bitworking.org/news/How_to_create_a_REST_Protocol):

  1. Ressourcen identifizieren, URIs designen (allerdings URI-Design nich so wichtig)
  2. Formate auswählen (D.h. welche Repräsentation die Ressouce hat (HTML, HTTP))
  3. Methodensemantik beschreiben
  4. Response-Codes abbilden (404, 403, 500…), von denen es in HTML schon für eigentlich jeden denkbaren Anwendungsfall einen gibt. Bspw. „Methode ist nicht mehr unter dieser URI erreichbar“

Die Vorteile von REST gegenüber „alten“ WS leigen laut dem Referenten auf der Hand:

  • Wirklich universelle Unterstützung (da nur HTTP und das kann wirklich „jeder“)
  • Mit Web-Services sind die Vorteile von HTTP eigentlich nicht zu nutzen, da sie protokollunabhängig sein müssen.
  • WS-Protokollunabhängigkeit ist ein Bug, kein Feature, weil sowieso (fast) jeder Web-Services über HTTP nutzt.

Fortgeschrittene Technologien

Für viele fortgeschrittene Technologien der Web-Services bietet REST auch bereits (teilweise von Haus aus) Unterstützung.

  • Asynchrone Kommunikation
    Wird unterstützt durch Code 202 Accepted + URI für Ergebnis, wenn bei einem Aufruf der URI das Ergebnis noch nicht vorliegt, wird einfach ein 404 geschickt
  • Reliable Messaging
  • 2-Phase-Commit Transaktionen
  • WS-Transfer, für was? HTTP-over-SOAP-over-HTTP???
  • UDDI
    Diese Technologie lässt sich relativ einfach über Atom realisierten

Zur Beschreibung der Web-Services schlägt der Referent vor, auf WSDLs zu verzichten und die Formate der Nachrichten einfach in XSD oder RelaxNG zu beschreiben. Nur zur Beschreibung der Operation und Datentypen sei WSDL zu kompliziert.

Mein Fazit:

Nachdem ich den Vortrag gehört hatte war ich zunächst extrem beeindruckt von den Prinzipien von REST. So einfach hätten Web-Services schon immer sein sollen! Nach einiger Reflektion darüber, vor allem im weiteren Verlauf der JAX, musste ich allerdings feststellen, dass es noch einer großen Kraftanstrengung bedarf, um REST auch bei Enterprise Applications durchzusetzen, denn die „alten“ Web-Services sind einfach viel zu präsent und haben einige weitere Technolgien nach sich gezogen, wie BPEL, das REST zum Beispiel überhaupt nicht berücksichtigt. Ohne WSDLs geht hier gar nichts.

Aber trotzdem hoffe ich, in Zukunft REST einsetzen zu können, vor allem wenn es darum geht „mal kurz“ eine Remote-Schnittstelle in eine Anwendung einzubauen.

Links:

Blog des Referenten: http://www.innoq.com/blog/st / Beitrag zum Vortrag
RESTlet(Java REST Framework): http://restlet.org

Advertisements



    Kommentar verfassen

    Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

    WordPress.com-Logo

    Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

    Twitter-Bild

    Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

    Facebook-Foto

    Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

    Google+ Foto

    Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

    Verbinde mit %s



%d Bloggern gefällt das: