REST Verben - welche Konvention ist "korrekt"

Question

Ich bin gut in die Implementierung eines REST-Dienstes (auf einer Windows CE-Plattform, wenn das wichtig ist) und ich begann mit IBM's general definitions von POST zum Erstellen (INSERTs) und PUT für die Aktualisierung zu verwenden.

Jetzt bin ich über Sun's definitions gelaufen, die genau das Gegenteil sind. Meine Frage ist also, welche ist die "allgemein akzeptierte" Definition? Oder gibt es sogar einen?

Answer 1

Der Nachteil der Verwendung von PUT zum Erstellen von Ressourcen besteht darin, dass der Client die eindeutige ID angeben muss, die das Objekt darstellt, das erstellt wird. Während es normalerweise möglich ist, dass der Client diese eindeutige ID generiert, bevorzugen die meisten Anwendungsentwickler, dass ihre Server (normalerweise über ihre Datenbanken) diese ID erstellen. In den meisten Fällen möchten wir unseren Server die Generierung von Ressourcen-IDs steuern. Also, was machen wir? Wir können zur Verwendung von POST anstelle von PUT wechseln.

Also: Put = UPDATE

Beitrag = INSERT

Answer 2

Wir verwenden POST = Erstellen, PUT = Update.

Warum? Es gibt keine gute Grund. Wir mussten uns eins aussuchen, und das war meine Entscheidung.

Bearbeiten. Wenn ich mir andere Antworten ansehe, wird mir klar, dass das Hauptproblem die Entscheidung treffen könnte.

Wir POST neue Einträge und geben ein JSON-Objekt mit dem generierten Schlüssel zurück. Es scheint, dass dies besser zu einer allgemein akzeptierten POST-Semantik passt.

Wir PUT zu vorhandenen Einträge mit einem vollständigen URI, der das Objekt identifiziert.

Answer 3

PUT kann für die Erstellung verwendet werden, wenn der Server den Client Kontrolle über einen Teil seiner URI Raum gewährt. Dies entspricht der Dateierstellung in einem Dateisystem: Wenn Sie eine Datei speichern, die noch nicht existiert, erstellen Sie sie, und wenn diese Datei existiert, ist das Ergebnis ein Update.

Allerdings fehlt PUT die Fähigkeit einer impliziten Absicht des Clients. Ziehen Sie eine Bestellung in Betracht: Wenn Sie PUT/orders/my-new-order eingeben, kann die Bedeutung immer nur die durch/orders/my-new-order angegebene Ressource aktualisieren, während POST/orders/bedeuten kann, dass ein neuer Auftrag vergeben wird Die POST-akzeptierende Ressource weist die entsprechende Semantik auf.

IOW, wenn Sie etwas als Nebeneffekt der Erstellung der neuen Ressource erreichen möchten, müssen Sie POST verwenden.

Jan

Answer 4

Der Grund POST als INSERT zu verwenden und als Update-PUT ist, dass der einzige nonidempotent POST und unsicherer Betrieb ist gemäß HTTP. Idempotent bedeutet, dass unabhängig davon, wie oft Sie die Operation anwenden, das Ergebnis immer dasselbe ist. In SQL ist INSERT die einzige nicht-identitätsfähige Operation und sollte daher auf POST abgebildet werden. UPDATE ist idempotent, so dass es auf PUT gemappt werden kann. Dies bedeutet, dass dieselbe PUT/UPDATE-Operation mehr als einmal angewendet werden kann, aber nur zuerst den Zustand unseres Systems/unserer Datenbank ändert.

Wenn Sie daher PUT für INSERT verwenden, wird die semantische HTTP-Anforderung, dass die PUT-Operation idempotent sein muss, unterbrochen.

Answer 5

Hier http://www.w3.org/Protocols/rfc2616/rfc2616.html ist die offizielle Anleitung, wie Sie das Verhalten der HTTP-Methoden implementieren.

Answer 6

Die Verben sind:

GET {path}: Abrufen der Ressource, deren Kennung {path}.

PUT {path}: Erstellen oder aktualisieren Sie die Ressource mit der ID {path}.

DELETE {path}: Löschen Sie die Ressource, deren Kennung {path} ist.

POST {path}: Rufen Sie eine Aktion auf, die von {path} identifiziert wird.

Wenn die Absicht, eine neue Ressource zu erstellen, können wir PUT verwenden, wenn wir wissen, was die Kennung der Ressource sein sollte, und wir können POST verwenden, wenn wir den Server zu bestimmen, die Kennung der neuen Ressource wollen.

Answer 7

Ich habe in letzter Zeit viel über die Konzepte und Implementierungen von REST gelesen und der allgemeine Konsens scheint zu sein: PUT wird zum Erstellen/Aktualisieren verwendet, abhängig davon, ob die Ressource bereits existiert oder nicht. POST wird verwendet, um eine Ressource an eine Sammlung anzuhängen.

Siehe HTTP/1.1 Methodendefinitionen http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

POST gestaltet ist ein einheitliches Verfahren zu ermöglichen, die folgenden Funktionen abdecken:

- Annotation of existing resources; 

    - Posting a message to a bulletin board, newsgroup, mailing 
    list, or similar group of articles; 

    - Providing a block of data, such as the result of submitting a 
    form, to a data-handling process; 

    - Extending a database through an append operation. 

das PUT Verfahren fordert, dass die umschlossene Einheit unter gespeichert werden die gelieferte Anfrage-URI. Wenn sich der Anfrage-URI auf eine bereits vorhandene -Ressource bezieht, sollte die beigefügte Entität als eine modifizierte -Version der auf dem Ursprungsserver befindlichen Version betrachtet werden.

Siehe auch die akzeptierte Antwort auf die Frage unter Understanding REST: Verbs, error codes, and authentication.