Content
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.