"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