REST – Representational State Transfer
- kann Informationen in den URI codieren
- somit sind die meisten Web-Sachen REST-konform
- 2000 von Roy Fielding
- seit 2014 RESTfull Apllication im WWW
- kann als asynchrones Verfahren genutzt werden
REST-Prinzip Client-Server
- Server stellt Dienst bereit
- Client fragt an
- skaliert gut
- funktioniert natürlich auch bidirektional: Dann braucht der Client auch einen Rest-Server
REST-Prinzip Zustandslosigkeit
- jede REST-Nachricht enthält alle Informationen, die für die Beteiligten nötig sind, sie zu verstehen => geschlossene Anfrage
- stateless Protocol
- begünstigt Skalierbarkeit
- Wie immer: Zustand durch zB Cookies
- aufwendigere Abfragen durch diese Kapselung + Zustandslosigkeit (D'oh!)
REST-Prinzip Caching
- HTTP Caching soll genutzt werden
- "Eine Anfrage, die nicht gestellt werden muss, ist die schnellste Anfrage" – Fielding
- Cache altert/wird schaal
REST-Prinzip Einheitliche Schnittstelle
- Einheitlichkeit ist einfach
- des weiteren sollen diese vier Prinzipien greifen:
1. Adressierbare Ressourcen
- URIs sind Ressourcen
- Einheitlichkeit durch Nutzung von URLs
- dadurch Weiterverwendbarkeit
2. Repräsentationen zur Veränderung von Ressourcen
- Flexibilität durch unterschiedliche Repräsentationen, dh unterschiedliche Antworten
- Veränderung nur durch Repräsentation
3. Selbstbeschreibende Nachrichten
- Standardmethoden zur Manipulation
- zB HTTP-Methoden
4. Hypermedia As The Engine Of Application State (HATEOAS)
- Navigation des Clients über URLs
- Server stellt diese bereit
- je nach Repräsentation werden URIs über Hypermedia dargestellt, zB
- durch href- und src-Attribute
- in definierten sowie dokumentierten JSON-Objekten bzw XML-Elementen
- HATEOAS-REST beschreibt einen endlichen Automaten
- dessen Zustand man mittels URIs verändert
- Schnittstelle veränderbar => loses Interface (iGgs zu SOAP)
Beispiel REST-Anfrage
REST-Request
GET /accounts/123abc HTTP/1.1
Host: bank.example.com
Accept: application/json
…
Beispiel REST-Antwort I
REST-Response
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: …
{
"account": {
"account_id": "123abc",
"balance": {
"currency": "EUR",
"value": 100.00
},
"links": {
"deposit": "/accounts/123abc/deposit",
"withdraw": "/accounts/123abc/withdraw",
"transfer": "/accounts/123abc/transfer",
"close": "/accounts/123abc/close"
}
}
}
Diese Antwort beinhaltet vier mögliche Links:
- deposit (einzahlen)
- withdraw (abbuchen)
- transfer (überweisen)
- close (kündigen)
Beispiel REST-Antwort II
Falls das Konto überzogen ist, kann nur noch Geld eingezahlt werden und keines mehr abgebucht oder überwiesen werden. Auch Konto kündigen entfällt.
Das verändert die Antwort.
REST-Response
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: …
{
"account": {
"account_id": "123abc",
"balance": {
"currency": "EUR",
"value": -100.00
},
"links": {
"deposit": "/accounts/123abc/deposit"
}
}
}
REST Conclutio
Es geht bei REST darum, dass es ein
- loses
- gekapseltes
Interface beschrieben wird.
Damit läßt sich also problemlos ein einfaches Interface über HTTP-GET zB zum Server-Steuern realisieren.
Damit läßt sich also einigermaßen ;) problemlos ein komplexes Interface über HTTP-POST zB zum Auf-dem-Server-Speichern realisieren.
Loses Interface -> Entwickler wählt flexibel, was er braucht -> weniger Arbeit => schnell und mehr PROFIT!
Wer möchte, kann sogar die ganzen (heute: cloudigen, ansonsten: immer gefährlichen) anderen HTTP-Methoden einsetzen, da kommt Freude auf!
Bei der Verwendung von JSON@REST (Ha!) entfällt auch der ganze SOAPsche Overhead.
Es ist also ein Entwickler-Träumchen!