Top Menu

Jump to content
Search ...
You are here:

Content

01) REST - Representational State Transfer

Geschichte

Das REST-Paradigma/REST-Prinzipien entwickelten sich asu dem von Roy Fielding 1994 entworfenen HTTP Object Model. Den REST-Architekturstil veröffentlichte er 2000 im Rahmen seiner Dissertation.

Die Prinzipien der Rest Architektur (https://de.wikipedia.org/wiki/Representational_State_Transfer)

Client Server Architektur

  • Der Server stellt einen Dienst bereit, dieser kann vom Client benutzt werden

Zustandslosigkeit

  • Jede Anfrage an den Server ist in sich geschlossen, es werden keine Zustandsinformationen zwischen zwei Nachrichten gespeichert.
  • Durch diese Zustandslosigkeit wird Skalierbarkeit ermöglicht. Die Last kann über mehrere Anwendungsserver verteilt werden

Caching

  • HTTP (siehe ETag) Caching mechanismen sollen verwendet werden

Einheitliche Schnittstelle

Addressierbarkeit von Ressourcen

Jede Ressource soll über eine URI (Uniform Resource Identifier) erreichbar sein, bzw. alles was über eine URI erreichbar ist, ist eine Resource

Beispiel

https://highscore.drlue.at/users/1

Stellt die Benutzerresource mit der ID 1 bereit.

Repräsentation zur Veränderung von Ressourcen

Der Webservice soll die Möglichkeit bieten, die Darstellung der Ressourcen entsprechend den wünschen des Clients anzupassen.

Beispiel

Zugriff auf die Ressource /users/1:

Webbrowser erhält html:

Request:

GET /users/1 HTTP/1.1
Host: highscore.drlue.at
Accept: text/html

<html>
  <table>
    <tr>td>Id:</td><td>1</td></tr>
    <tr>td>Name:</td><td>Alfons</td></tr>
    <tr><td>Highscore:</td><td>1000</td></tr>
  </table>
</html>

App erhält json (Javascript object notation):

GET /users/1 HTTP/1.1
Host: highscore.drlue.at
Accept: application/json

{
  "id" : 1,
  "name" : "Alfons",
  "highscore" : 1000
}
Einheitliche Schnittstelle

REST-Nachrichten sollen selbstbeschreibend sein. Manipulation von Ressourcen erfolgt über Standardmethoden.

Hiefür eigenen sich die vom HTTP Protokoll bereitgestellten Verben (Methoden):

  • GET - Ressource holen
  • PUT - Ressource verändern
  • POST - Ressource erstellen
  • DELETE - Ressource löschen
HATEOAS (Hypermedia as the Engine of Application State)

Wichtigste Eigenschaft nach Fielding, wir werden trotzdem aktuell nicht darauf eingehen. Für Informationen siehe: https://de.wikipedia.org/wiki/Representational_State_Transfer#HATEOAS

Mehrschichtige Systeme

Systeme sollen mehrschichtig aufgebaut sein, jedoch nur eine Ebene soll zugänglich für den Anwender sein.

Code on Demand (optional)

Der Webservice soll Code der beim Client ausgeführt wird zur Verfügung stellen können.