Soll eine RESTful "PUT"-Operation etwas zurückgeben....

Question

Ich frage mich, welche Meinungen die Leute zu einer RESTful PUT-Operation haben, die in der Antwort keine Daten (null) zurückgibt.

Answer 1

Die HTTP-Spezifikation (RFC 2616) enthält eine Reihe von Empfehlungen, die anwendbar sind. Hier ist meine Interpretation:

• HTTP-Statuscode 200 OK für eine erfolgreiche Aktualisierung einer vorhandenen Ressource durch PUT. Es wird kein Antwortkörper benötigt. (Gemäß Abschnitt 9.6 ist 204 No Content noch angemessener.)
• HTTP-Statuscode 201 Created für einen erfolgreichen PUT einer neuen Ressource, wobei die spezifischste URI für die neue Ressource im Location-Headerfeld zurückgegeben wird und alle anderen relevanten URIs und Metadaten der Ressource im Antwortkörper wiedergegeben werden. (RFC 2616 Abschnitt 10.2.2)
• HTTP-Statuscode 409 Conflict für einen nicht erfolgreichen PUT aufgrund einer Änderung durch eine 3. Partei, mit einer Liste von Unterschieden zwischen dem versuchten Update und der aktuellen Ressource im Antwortkörper. (RFC 2616 Abschnitt 10.4.10)
• HTTP-Statuscode 400 Bad Request für einen nicht erfolgreichen PUT, mit natürlichsprachlichem Text (z. B. Englisch) im Antwortkörper, der erklärt, warum der PUT fehlgeschlagen ist. (RFC 2616 Abschnitt 10.4)

Hinweis: RFC 2616 war die neueste Spezifikation zum Zeitpunkt der Beantwortung dieser Frage, aber der RFC wurde inzwischen ersetzt. Beim Verweis auf einen Standard kann es hilfreich sein zu überprüfen, ob Sie den neuesten verwenden.

Answer 2

Im Gegensatz zu den meisten Antworten hier denke ich tatsächlich, dass PUT die aktualisierte Ressource zurückgeben sollte (zusätzlich zum HTTP-Code natürlich).

Der Grund, warum Sie die Ressource als Antwort auf den PUT-Vorgang zurückgeben möchten, ist, dass der Server bei Übermittlung einer Ressourcendarstellung auch einige Verarbeitungen auf diese Ressource anwenden kann. Daher möchte der Client wissen, wie diese Ressource nach erfolgreichem Abschluss der Anfrage aussieht. (sonst müsste er eine weitere GET-Anfrage senden).

Answer 3

Wenn das Backend der REST-API eine SQL-Relationdatenbank ist, dann

1. sollten Sie RowVersion in jedem Datensatz haben, der aktualisiert werden kann (um das Problem des verlorenen Updates zu vermeiden)
2. sollten Sie immer eine neue Kopie des Datensatzes nach PUT zurückgeben (um die neue RowVersion zu erhalten).

Wenn Ihnen verlorene Updates egal sind oder wenn Sie Ihre Clients dazu zwingen möchten, sofort nach einem PUT ein GET durchzuführen, dann geben Sie nichts von PUT zurück.

Answer 4

Ich denke, es ist möglich, dass der Server Inhalte als Antwort auf ein PUT zurückgeben kann. Wenn Sie ein Antwort-Umschlagformat verwenden, das das Laden von Daten erlaubt (wie das von ember-data konsumierte Format), können Sie auch andere Objekte einschließen, die möglicherweise über Datenbank-Trigger usw. geändert wurden. (Das Laden von Daten dient ausdrücklich zur Reduzierung der Anzahl von Anfragen, und dies scheint ein guter Ort zum Optimieren zu sein.)

Wenn ich einfach den PUT akzeptiere und nichts zurückzumelden habe, verwende ich den Statuscode 204 ohne Body. Wenn ich etwas zu melden habe, verwende ich den Statuscode 200 und füge einen Body hinzu.

Answer 5

Der Http-Methoden "PUT" kann je nach Ausführungsstatus auf dem übergebenen Request-URI unterschiedliche Http-Status haben. Die unten stehende Tabelle kann dabei helfen zu verstehen -