REST ist das zugrunde liegende Architekturprinzip des Webs. Das Erstaunliche am Web ist die Tatsache, dass Clients (Browser) und Server auf komplexe Weise interagieren können, ohne dass der Client zuvor etwas über den Server und die darin gehosteten Ressourcen weiß. Die Hauptbeschränkung besteht darin, dass sowohl der Server als auch der Client sich auf die verwendeten Medien einigen müssen , bei denen es sich im Web um HTML handelt .
Für eine API, die den Prinzipien von REST entspricht, muss der Client nichts über die Struktur der API wissen. Der Server muss vielmehr alle Informationen bereitstellen, die der Client für die Interaktion mit dem Dienst benötigt. Ein Beispiel hierfür ist ein HTML-Formular : Der Server gibt den Speicherort der Ressource und die erforderlichen Felder an. Der Browser weiß nicht im Voraus, wo die Informationen übermittelt werden sollen, und er weiß nicht im Voraus, welche Informationen übermittelt werden sollen. Beide Arten von Informationen werden vollständig vom Server bereitgestellt. (Dieses Prinzip heißt HATEOAS : Hypermedia als Motor des Anwendungsstatus .)
Wie trifft dies auf HTTP zu und wie kann es in der Praxis implementiert werden? HTTP orientiert sich an Verben und Ressourcen. Die beiden Verben im Mainstream-Gebrauch sind GETund POST, von denen ich denke, dass jeder sie erkennen wird. Der HTTP-Standard definiert jedoch mehrere andere wie PUTund DELETE. Diese Verben werden dann gemäß den Anweisungen des Servers auf Ressourcen angewendet.
Stellen wir uns zum Beispiel vor, wir haben eine Benutzerdatenbank, die von einem Webdienst verwaltet wird. Unser Service verwendet ein auf JSON basierendes benutzerdefiniertes Hypermedia, für das wir den Mimetyp zuweisen application/json+userdb(möglicherweise werden auch ein application/xml+userdbund application/whatever+userdb- viele Medientypen unterstützt). Der Client und der Server wurden beide so programmiert, dass sie dieses Format verstehen, aber sie wissen nichts voneinander. Wie Roy Fielding betont:
Eine REST-API sollte fast den gesamten beschreibenden Aufwand für die Definition der Medientypen verwenden, die zur Darstellung von Ressourcen und zur Steuerung des Anwendungsstatus verwendet werden, oder für die Definition erweiterter Beziehungsnamen und / oder hypertextfähiger Markierungen für vorhandene Standardmedientypen.
Eine Anforderung für die Basisressource /könnte Folgendes zurückgeben:
Anfrage
GET /
Accept: application/json+userdb
Antwort
200 OK
Content-Type: application/json+userdb
{
"version": "1.0",
"links": [
{
"href": "/user",
"rel": "list",
"method": "GET"
},
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
Aus der Beschreibung unserer Medien wissen wir, dass wir Informationen zu verwandten Ressourcen in Abschnitten finden können, die als "Links" bezeichnet werden. Dies wird als Hypermedia-Steuerelement bezeichnet . In diesem Fall können wir anhand eines solchen Abschnitts erkennen, dass wir eine Benutzerliste finden können, indem wir eine weitere Anfrage stellen für /user:
Anfrage
GET /user
Accept: application/json+userdb
Antwort
200 OK
Content-Type: application/json+userdb
{
"users": [
{
"id": 1,
"name": "Emil",
"country: "Sweden",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
{
"id": 2,
"name": "Adam",
"country: "Scotland",
"links": [
{
"href": "/user/2",
"rel": "self",
"method": "GET"
},
{
"href": "/user/2",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/2",
"rel": "delete",
"method": "DELETE"
}
]
}
],
"links": [
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
Wir können viel aus dieser Antwort sagen. Zum Beispiel wissen wir jetzt , wir einen neuen Benutzer durch erstellen POSTzu ing /user:
Anfrage
POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Karl",
"country": "Austria"
}
Antwort
201 Created
Content-Type: application/json+userdb
{
"user": {
"id": 3,
"name": "Karl",
"country": "Austria",
"links": [
{
"href": "/user/3",
"rel": "self",
"method": "GET"
},
{
"href": "/user/3",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/3",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
Wir wissen auch, dass wir vorhandene Daten ändern können:
Anfrage
PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Emil",
"country": "Bhutan"
}
Antwort
200 OK
Content-Type: application/json+userdb
{
"user": {
"id": 1,
"name": "Emil",
"country": "Bhutan",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
Beachten Sie, dass wir verschiedene HTTP - Verben verwenden ( GET, PUT, POST, DELETEetc.) , diese Ressourcen zu manipulieren, und dass das einzige Wissen , das wir auf der Client-Teil vermuten ist unsere Mediendefinition.
Weiterführende Literatur:
(Diese Antwort wurde vielfach kritisiert, weil sie den Punkt verfehlt hatte. Zum größten Teil war dies eine faire Kritik. Was ich ursprünglich beschrieben habe, entsprach eher der Art und Weise, wie REST vor einigen Jahren normalerweise implementiert wurde, als ich es tat schrieb dies zuerst und nicht seine wahre Bedeutung. Ich habe die Antwort überarbeitet, um die wahre Bedeutung besser darzustellen.)
