Was sollte laut "REST-Ideologie" im Antworttext für PUT / POST / DELETE-Anforderungen enthalten sein?
Was ist mit Rückkehrcodes? Ist HTTP_OKgenug
Was ist der Grund für solche Konventionen, wenn überhaupt?
Ich habe einen guten Beitrag gefunden, der POST / PUT-Unterschiede beschreibt: POST vs PUT Aber meine Frage wird immer noch nicht beantwortet.
Antworten:
Verzeihen Sie die Wendigkeit, aber wenn Sie REST über HTTP ausführen, beschreibt RFC7231 genau, welches Verhalten von GET, PUT, POST und DELETE erwartet wird.
Update (3. Juli 14):
Die HTTP-Spezifikation definiert absichtlich nicht, was von POST oder DELETE zurückgegeben wird. Die Spezifikation definiert nur, was definiert werden muss. Der Rest bleibt dem Implementierer überlassen.
Insgesamt lauten die Konventionen „denken Sie, Sie liefern nur Webseiten“.
Für einen PUT würde ich dieselbe Ansicht zurückgeben, die Sie erhalten würden, wenn Sie unmittelbar danach einen GET durchführen würden. das würde zu einer 200 führen (vorausgesetzt, das Rendern ist natürlich erfolgreich). Für einen POST würde ich eine Umleitung zu der erstellten Ressource durchführen (vorausgesetzt, Sie führen einen Erstellungsvorgang durch; wenn nicht, geben Sie einfach die Ergebnisse zurück). Der Code für eine erfolgreiche Erstellung ist ein 201, der wirklich der einzige HTTP-Code für eine Umleitung ist, der nicht im Bereich von 300 liegt.
Ich war noch nie glücklich darüber, was ein DELETE zurückgeben sollte (mein Code erzeugt derzeit ein HTTP 204 und in diesem Fall einen leeren Körper).
PUTAnforderung die nächste Seite zurückgibt, scheint dies eine schlechte Praxis zu sein, da das Aktualisieren der resultierenden Seite dazu führt, dass die Anforderung erneut ausgeführt wird. Stattdessen ist es für mich sinnvoll, eine Umleitung durchzuführen, vorausgesetzt, Sie haben es mit synchronen Anforderungen zu tun.
PUTAnforderung sendet, wodurch die Daten zurückgesetzt werden. Wenn beispielsweise zwei Personen auf dieselbe Seite verweisen, nimmt eine eine Aktualisierung vor, die andere führt eine Aktualisierung durch. Wenn die erste Person aktualisiert wird, um das Ergebnis zu sehen, führt dies tatsächlich dazu, dass die Dinge vor der zweiten Person zurückgesetzt werden ihre Veränderungen.
Das Erstellen einer Ressource wird im Allgemeinen dem POST zugeordnet. Dies sollte den Speicherort der neuen Ressource zurückgeben. In einem Rails-Gerüst leitet ein CREATE beispielsweise zur SHOW für die neu erstellte Ressource um. Der gleiche Ansatz mag für die Aktualisierung (PUT) sinnvoll sein, aber das ist weniger eine Konvention. Ein Update muss nur den Erfolg anzeigen. Ein Löschen muss wahrscheinlich auch nur den Erfolg anzeigen. Wenn Sie umleiten möchten, ist die Rückgabe der Ressourcenliste wahrscheinlich am sinnvollsten.
Erfolg kann durch HTTP_OK angezeigt werden, ja.
Die einzige feste Regel in dem, was ich oben gesagt habe, ist, dass ein CREATE den Speicherort der neuen Ressource zurückgeben soll. Das scheint mir ein Kinderspiel zu sein; Es ist durchaus sinnvoll, dass der Kunde auf den neuen Artikel zugreifen kann.
Beim RFC7231 spielt es keine Rolle und ist möglicherweise leer
Wie wir die auf json api standard basierende Lösung im Projekt implementieren:
post / put: Gibt Objektattribute wie in get aus (Feldfilter / Relationen gelten gleich)
Löschen: Daten enthalten nur Null (für die Darstellung eines fehlenden Objekts)
Status für Standardlöschung: 200
Ich mag Alfonso Tienda Antwort vom HTTP-Statuscode zum Aktualisieren und Löschen?
Hier sind einige Tipps:
LÖSCHEN
200 (wenn Sie zusätzliche Daten in der Antwort senden möchten) oder 204 (empfohlen).
202 Operation gelöscht wurde noch nicht festgeschrieben.
Wenn nichts zu löschen ist, verwenden Sie 204 oder 404 (DELETE-Operation ist idempotent, Löschen eines bereits gelöschten Elements ist erfolgreich , sodass Sie 204 zurückgeben können , aber es ist wahr, dass idempotent nicht unbedingt dieselbe Antwort impliziert).
Andere Fehler:
- 400 Bad Request (Falsche Syntax oder eine schlechte Abfrage ist seltsam, aber möglich).
- 401 Fehler bei nicht autorisierter Authentifizierung
- 403 Verboten : Autorisierungsfehler oder ungültige Anwendungs-ID.
- 405 Nicht erlaubt . Sicher.
- 409 Ressourcenkonflikte können in komplexen Systemen möglich sein.
- Und 501 , 502 bei Fehlern.
STELLEN
Wenn Sie ein Element einer Sammlung aktualisieren
- 200/204 mit den gleichen Gründen wie oben gelöscht .
- 202, wenn die Operation noch nicht festgeschrieben wurde.
Das referenzierte Element existiert nicht:
PUT kann 201 sein (wenn Sie das Element erstellt haben, weil dies Ihr Verhalten ist)
404 Wenn Sie keine Elemente über PUT erstellen möchten.
400 Bad Request (Fehlerhafte Syntax oder eine fehlerhafte Abfrage häufiger als bei DELETE).
401 Nicht autorisiert
403 Verboten : Authentifizierungsfehler oder ungültige Anwendungs-ID.
405 Nicht erlaubt . Sicher.
409 Ressourcenkonflikte können in komplexen Systemen wie in DELETE möglich sein.
422 Nicht verarbeitbare Entität Es hilft, zwischen einer "fehlerhaften Anforderung" (z. B. fehlerhaftem XML / JSON) und ungültigen Feldwerten zu unterscheiden
Und 501 , 502 bei Fehlern.