Die Idee von RE Präsentations S tate T ransfer geht es nicht um Daten auf einfachste Weise möglich , den Zugriff.
Sie haben vorgeschlagen, Post-Anfragen für den Zugriff auf JSON zu verwenden. Dies ist eine absolut gültige Methode für den Zugriff auf / die Bearbeitung von Daten.
REST ist eine Methode für den sinnvollen Zugriff auf Daten. Wenn Sie eine Anfrage in REST sehen, sollte sofort klar sein, was mit den Daten passiert.
Beispielsweise:
GET: /cars/make/chevrolet
wird wahrscheinlich eine Liste von Chevy-Autos zurückgeben. Eine gute REST-API kann sogar einige Ausgabeoptionen in den Querystring einbinden, wie ?output=jsonoder ?output=htmldie es dem Accessor ermöglichen würden, zu entscheiden, in welchem Format die Informationen codiert werden sollen.
Nach einem wenig darüber nachzudenken , wie man vernünftigerweise incorporate Typisierung in einen REST - API, habe ich festgestellt , dass der beste Weg , um die Art der Daten , über die bereits vorhandene Dateierweiterung würde explizit angeben, wie etwa .js, .json, .html, oder .xml. Eine fehlende Dateierweiterung würde standardmäßig das Standardformat verwenden (z. B. JSON). Eine nicht unterstützte Dateierweiterung kann einen 501 Not ImplementedStatuscode zurückgeben .
Ein anderes Beispiel:
POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }
wird wahrscheinlich einen neuen Chevy Malibu in der Datenbank mit den dazugehörigen Farben erstellen. Ich sage wahrscheinlich, da die REST-API nicht direkt mit der Datenbankstruktur verknüpft sein muss. Es ist nur eine Maskierungsschnittstelle, damit die wahren Daten geschützt werden (denken Sie an Accessoren und Mutatoren für eine Datenbankstruktur).
Jetzt müssen wir uns dem Thema Idempotenz zuwenden . Normalerweise implementiert REST CRUD über HTTP. HTTP verwendet GET, PUT, POSTund DELETEfür die Anforderungen.
Eine sehr vereinfachte Implementierung von REST könnte das folgende CRUD-Mapping verwenden:
Create -> Post
Read -> Get
Update -> Put
Delete -> Delete
Bei dieser Implementierung gibt es ein Problem: Post ist als nicht idempotente Methode definiert. Dies bedeutet, dass nachfolgende Aufrufe derselben Post-Methode zu unterschiedlichen Serverzuständen führen. Get, Put und Delete sind idempotent. Dies bedeutet, dass ein mehrmaliger Aufruf zu einem identischen Serverstatus führen sollte.
Dies bedeutet, dass eine Anfrage wie:
Delete: /cars/oldest
könnte tatsächlich implementiert werden als:
Post: /cars/oldest?action=delete
Wohingegen
Delete: /cars/id/123456
führt zu demselben Serverstatus, wenn Sie ihn einmal oder 1000 Mal aufrufen.
Eine bessere Möglichkeit, das Entfernen des oldestArtikels zu handhaben, besteht darin, Folgendes anzufordern:
Get: /cars/oldest
und verwenden Sie die IDaus den resultierenden Daten, um eine deleteAnfrage zu stellen:
Delete: /cars/id/[oldest id]
Ein Problem bei dieser Methode wäre, wenn /carszwischen der /oldestAnforderung und der Ausgabe ein weiteres Element hinzugefügt würde delete.