Eine Einführung in REST

Im Zusammenhang mit Webservices existiert seit einiger Zeit ein Begriff, dem zunehmend mehr Beachtung geschenkt wird: Representational State Transfer. Der Ausdruck entstammt der Dissertation von Roy Fielding aus dem Jahr 2000. In seiner Arbeit stellte Fielding bisher vorherrschende Architekturstile im Softwaredesign in Frage und zeigte grundlegende, neue Lösungswege auf - kurz REST.

“…the most efficient network request is one that doesn’t use the network.”
– Roy Fielding

Representational State Transfer

Ein gängiger Irrglaube ist, das REST ein Protokoll wie HTTP oder SOAP darstellt. Das ist falsch – REST ist ein Paradigma der Softwareentwicklung und kein Protokoll.

Was ist also REST und wann kann eine Architektur in der Softwareentwicklung als RESTful bezeichnet werden? Im Prinzip ist eine Softwarearchitektur RESTful, wenn die nachfolgenden sechs Bedingungen erfüllt werden:

1) Client Server Architektur
Eine einheitliche Schnittstelle trennt Client und Server, woraus Sparation of Concerns resultiert.

2) Statelessness
Zustandslose Interaktion zwischen Client und Server. Alle REST Nachrichten enthalten genau die Informationen, die für den Client oder den Server ausschlaggebend sind, um die jeweilige Nachricht zu verstehen.

3) Cacheability
Nachrichten vom Server (Responses) müssen sich selbst als cacheable oder nicht cacheable auszeichnen, damit der Client keine veralteten Daten zwischenspeichert.

4) Layered system
Aufgrund eines Schichtenmodells hat der Client keine Information darüber, ob er direkt mit dem finalen Server oder nur einem auf dem Weg liegenden Server verbunden ist.

5) Uniform interface
Jeder Dienst, jede Methode oder jeder Status besitzt eine eindeutige Adresse.

6) Code on demand
Client Flexibilität, der Server kann temporär die Funktionalität des Clients so erweitern oder anpassen, dass dieser ausführbaren Code wie beispielsweise ein Java Applet oder JavaScript vom Server erhält. Diese Bedingung ist jedoch optional.

REST Operationen

Jeder dem REST Standard entsprechende Dienst bietet verschiedene Möglichkeiten zum Informationsaustausch an. Dabei erfolgt jeder Request vom Client an den Server und zurück über das HTTP Protokoll und bedient sich auch dessen Funktionalität. Alle möglichen Operationen entsprechen somit einem der nachfolgenden Typen:

GET
Gibt einen einzelnen oder eine Sammlung von Einträgen zurück.

POST
Erzeugen eines neuen Eintrags.

PUT
Update.( Aktualisierung) eines bestehenden Eintrags.

DELETE
Löschen eines Eintrags.

PATCH 
Update von einzelnen Eigenschaften eines existierenden Eintrags.

Im GET Request stellt die Antwort vom Server die Daten zur Verfügung. Bei POST und PUT, sendet der Client die Daten im Request Body zurück an den Server. Bei DELETE werden keine Daten ausgetauscht. POST, GET, PUT und DELETE werden von einem Server als Create, Retrieve, Update und Delete (CRUD) Schnittstellen unterstützt. Diese Funktionalität ist jedoch nicht verpflichtend und hängt letztendlich von der Implementierung der API ab. So könnte ein Service beispielsweise nur das Abfragen Von Daten mittels GET Operation zulassen.

Das beste Beispiel für einen voll funktionsfähigen REST Service stellt das Word Wide Web dar. Dieser Umstand ist wenig überraschend, da Roy Fielding einen wesentlichen Beitrag zur Standardisierung des HTTP Protokolls geleistet hat. Seine Dissertation befasste sich schließlich auf eine abstrahierte Art und Weise mit den Design Grundregeln der HTTP Architektur. Ein RESTful Service profitiert also von der Architektur und der Art und Weise wie das Web arbeitet. Die Schlüsselelemente eines REST Service werden als nächstes kurz erklärt.

URI
Ein Uniform Resource Identifier (URI) identifiziert und lokalisiert eine spezifische Ressource über eine Zugriffsmethode (wie beispielswese das HTTP) in einem Netzwerk. Jede Ressource, die wichtig genug ist, damit Benutzer darauf zugreifen können, muss zumindest eine URI aufweisen. Diese URI kann auch als Lesezeichen gespeichert werden, damit sie immer wieder erneut aufgerufen werden kann.

Links
Ein Server stellt eine sich selbst beschreibende Ressource, die bearbeitet werden kann, mit Hilfe eines Hypermedia Links zur Verfügung. Die formale Beschreibung dieses Konzepts ist als ‘'Hypermedia as the Engine of Application State” (HATEOAS) bekannt. Wenn man genauer analysiert, was sich eigentlich hinter diesem einschüchternden Konzept verbirgt, lässt sich feststellen, dass sich alles nur um Links dreht. Links sind aus HTML gut bekannt – sie ermöglichen die Navigation von einer Webseite zu einer anderen.

Uniform Interface
Eines der wesentlichsten Features von einem RESTful Service ist, dass dieser bestehende HTTP Verben verwendet, um auf adressierbare Ressourcen über eine URI zugreifen zu können. Zusammengefasst, werden hier CRUD Operationen auf Ressourcen einer Datenbank über HTTP Verben ausgeführt.

Stateless Communication
Alle RESTful Services unterstützen Stateless Communication, sprich eine zustandslose Kommunikation. Darunter versteht sich, dass der Client sämtliche Informationen in einem Request zur Verfügung stellen muss, damit der Request vom Server ausgeführt werden kann. Ein Session Status wird vom Server nicht gehalten – Session Informationen werden stattdessen am Client gespeichert.

Mehrfache Repräsentationen einer Ressource
Jeder RESTful arbeitende Server kann verschiedene Repräsentationen einer Datenquelle liefern. Zu den Repräsentationen zählen beispielsweise JSON (JavaScript Object Notation) oder XML (Extensible Markup Language). Der Vorteil von JSON ist zum Beispiel, dass dieses Format leichter von JavaScript Clients konsumiert werden kann.

Wenn sie mehr zum Thema REST und die Arbeit mit Daten und modernen Webservices erfahren und lernen möchten, würden wir uns freuen Sie in unserer aktuellen Schulung zum Thema Web API im .NET Umfeld begrüßen zu dürfen.

Kommentare sind geschlossen