Читать книгу GraphQL - Dominik Kress - Страница 23

REST steht für Representational State Transfer [21]. Es handelt sich dabei nicht um eine konkrete Technologie und keinen Standard, sondern vielmehr um einen Architekturstil oder ein Programmierparadigma, das 2000 von Roy Fielding in seiner Dissertation mit dem Titel Architectural Styles and the Design of Network-based Software Architectures konzipiert wurde.

REST ist ein Konzept, in dem Daten als Ressourcen gesehen werden. Diese können über eine eindeutige Adresse – eine URI – identifiziert werden und sind in einem spezifischen Format – nach Fieldings ursprünglicher Vision XML – repräsentiert. Eine Ressource kann sowohl ein einzelnes Objekt als auch eine Sammlung – also Collection – von Objekten sein (siehe Abbildung 1–2).

Abb. 1–2 Ressourcen, Repräsentation und URI im Zusammenhang

Kommunizieren kann der Client mit den Ressourcen bei einer RESTful API über HTTP und dessen Methoden. Diese sind POST, GET, PUT sowie DELETE und bilden die CRUD-Operationen (Create, Read, Update, Delete). Die Kommunikation findet dabei in einem Request/Response-Muster statt. Der Client stellt über die HTTP-Methoden entsprechende Requests an die gewünschte Ressource des API, und der Server antwortet mit einer Response: bei einem lesenden Zugriff beispielsweise mit der Repräsentation dieser Ressource im Body der Response.

Ein Request auf solch ein RESTful API über die Konsole – mit einem sogenannten cURL-Befehl – würde beispielhaft dann wie folgt aussehen:

$ curl -X GET "https://api.shop.com/user/5"

Listing 1–1 REST GET Request

Hier fordert der Client einen lesenden Zugriff auf den User mit der ID 5. Auf diesen Request würde er nun vom Server folgende Response erhalten:

< HTTP/1.1 200 OK

< Status: 200 OK

< Content-Length: 1782

< Content-Type: application/json

<

{"id":"5","username":"luke"}

Listing 1–2 REST GET Response

Der HTTP-Statuscode zeigt an, dass der Request erfolgreich abgearbeitet wurde. Die Rückgabe enthält mit dem JSON-Objekt am Ende die Repräsentation der Ressource des Users mit der id = 5. Ähnlich funktioniert auch ein schreibender Request des Clients:

$ curl -X PUT "https://api.shop.com/user/5" -d

'{"id":"5","username":"leia"}'

Listing 1–3 REST PUT

Bei diesem Beispiel handelt es sich um einen Request zum Überschreiben des Nutzers mit der id = 5. Die neue Objektrepräsentation wird im Request mitgeliefert und ersetzt serverseitig die bisherige Repräsentation der Ressource.

Ein weiterer Punkt in Fieldings Definition von REST – oder eher noch: sein Hauptaugenmerk bei der Architektur – war das sogenannte Hypermedia as the Engine of Application State oder auch HATEOS. Hierbei sollte der Zugriff des Clients lediglich auf einen initialen Endpunkt des Service beschränkt werden. Dieser hält neben der eigenen Repräsentation auch Verbindungen zu anderen Ressourcen bereit. Ein Client kann also alle möglichen Endpunkte dynamisch entdecken – ähnlich dem Durchklicken verschiedener Links auf einer Webseite.

HATEOS wird jedoch selten strikt durchgesetzt, weshalb nicht unbedingt Fieldings Vision von REST, sondern eher eine pragmatischere Interpretation heute als REST bezeichnet wird und weitläufig verbreitet ist.