"Warum Leute, die stabile Plattformen wollen REST einsetzen"
Representational
State
TRANSFER
PHD-THESIS 2000
Client-SERVER
! events
!reactive
! pubsub
! callback
Zustandslosigkeit
! session
!user-id-in-url
ADRESSIERBARKEIT VON REsSOURCEN
Jede Ressource hat eine eindeutige URL
Repräsentationen zur Veränderung
Das Übergabeformat kann für Änderungen verwendet werden.
JSON, XML, YAML, HTML
HTTP-VERBS
HTTP wird nicht nur als Transportschicht, sondern auch als Interaktionsmodell und als Organisation verwendet.
IDEMPOTENz
Addition von 0.
Multiplikation von 1.
Einmaliger Aufruf hat den gleichen Effekt wie mehrmaliger Aufruf.
POST ist nicht idempotent, PATCH kann es sein, alles andere ist.
Methoden
GET
Fordert die angegebene Ressource vom Server an. GET weist keine Nebeneffekte auf. Der Zustand am Server wird nicht verändert, weshalb GET als sicher bezeichnet wird.
Idempotent.
GET
PUT
Die angegebene Ressource wird angelegt. Wenn die Ressource bereits existiert, wird sie geändert.
Idempotent.
PATCH
Ein Teil der angegebenen Ressource wird geändert. Hierbei sind Nebeneffekte erlaubt.
Je nach Glaubensrichtung Idempotent oder auch nicht.
DELETE
Löscht die angegebene Ressource.
Idempotent.
Aber: 200 beim ersten, 404 beim nächsten ist ok.
HEAD
Fordert Metadaten zu einer Ressource an.
Idempotent.
OPTIONS
Prüft, welche Methoden auf einer Ressource zur Verfügung stehen.
Idempotent.
CONNECT, TRACE
Nicht so wichtig.
Idempotent.
POST
Fügt eine neue (Sub-)Ressource unterhalb der angegebenen Ressource ein. Da die neue Ressource noch keinen URI besitzt, adressiert der URI die übergeordnete Ressource. Als Ergebnis wird der neue Ressourcenlink dem Client zurückgegeben. POST kann im weiteren Sinne auch dazu verwendet werden, Operationen abzubilden, die von keiner anderen Methode abgedeckt werden.
NICHT Idempotent!
POST
As an example, imagine a service that allows creation of hosted servers, which will be named by the service:
POST http://api.contoso.com/account1/servers
The response would be something like:
201 Created
Location: http://api.contoso.com/account1/servers/server321
Where "server321" is the service-allocated server name.
CACHING
(Deshalb braucht es Idempotenz)
(Deshalb braucht es Idempotenz)
EINHEITLICHE SCHNITTSTELLE
... damit man zB die /customer/1234 Urls mit einem reverse Proxy zu einem anderen Service schicken kann ohne die Struktur zu ändern.
SELBSTBESCHREIBENE NACHRICHTEN
HTTP/1.1 200 OK Content-Type: text/html <!DOCTYPE html> <html>
MEHRSCHICHTIGE SYSTEME
Layered System:
ich brauche nur das nächste Layer zu kennen.
CODE ON DEMAND
Clients und Server können generiert werden.
(Deshalb OPENAPI, Swagger & Co)
Und vieles mehr ...
- API Validation
- automatisches API Testing
- Auto Mocking
- Auto Mock Validation
- Security-Fuzzing
- uvm
REST VERSIONING
http://api.example.com/v1/customer/12 http://apiv1.example.com/customer/12
Accept-Version: v1 Accept: application/vnd.example.v1;version=1
REST MATURITY 0
- RPC-Mechanismus a la XML-RPC oder SOAP
- eine einzige URL für den ganzen Service
- eine einzige HTTP-Methode (POST)
REST MATURITY 1
- verschiedene URIs und Ressourcen
- aber nur eine HTTP-Methode (POST)
REST MATURITY 2
- verschiedene URIs und Ressourcen
- passende HTTP-Methoden
- Alles != POST ist idempotent
- verschiedene URIs und Ressourcen
- passende HTTP-Methoden
- Alles != POST ist idempotent
REST MATURITY 3
- verschiedene URIs und Ressourcen
- passende HTTP-Methoden
- Links erlauben Navigation und Beziehungen zwischen Ressourcen
- HATEOAS
Antipattern
- POST statt PUT, GET, DELETE
- Still RPC in my brain:
DELETE /customer/delete?name=Hartmann statt
DELETE /customer/:id - idempotentes POST
- NO HATEoas: keine Hypermedia-Links
- "REST ist auch nur CRUD"
- Everything is an Entity & Fallacy of nested Ressources:
/consumer/{consumerid}/costumer/{customerid}/cart{1}
HATEOAS
HYPERMEDIA AS THE ENGINE OF APPLICATION STATE
No REST for the Wicked
By Johann-Peter Hartmann
No REST for the Wicked
- 418