Welchen Statuscode soll ich für UPDATE( PUT) und DELETE(zB Produkt erfolgreich aktualisiert) einstellen ?
HTTP-Statuscode zum Aktualisieren und Löschen?
Antworten:
Für eine PUT- Anforderung: HTTP 200 oder HTTP 204 sollten "Ressource erfolgreich aktualisiert" bedeuten.
Für eine DELETE- Anforderung: HTTP 200 oder HTTP 204 sollten "Ressource erfolgreich gelöscht" bedeuten. HTTP 202 kann auch zurückgegeben werden, was bedeuten würde, dass die Anweisung vom Server akzeptiert wurde und die "Ressource zum Löschen markiert wurde".
Wenn eine vorhandene Ressource geändert wird, MÜSSEN entweder die Antwortcodes 200 (OK) oder 204 (Kein Inhalt)> gesendet werden, um den erfolgreichen Abschluss der Anforderung anzuzeigen.
Eine erfolgreiche Antwort sollte 200 (OK) sein, wenn die Antwort eine Entität enthält, die den Status beschreibt, 202 (Akzeptiert), wenn die Aktion noch nicht ausgeführt wurde, oder 204 (Kein Inhalt), wenn die Aktion ausgeführt wurde, die Antwort jedoch nicht enthält eine Entität.
Quelle: W3.org: HTTP / 1.1-Methodendefinitionen
HTTP 200 OK: Standardantwort für erfolgreiche HTTP-Anforderungen. Die tatsächliche Antwort hängt von der verwendeten Anforderungsmethode ab.
HTTP 204 Kein Inhalt: Der Server hat die Anforderung erfolgreich verarbeitet, gibt jedoch keinen Inhalt zurück
40
Sehr nützlicher Beitrag! Ich frage mich jedoch, wie der HTTP-Statuscode lauten soll, wenn die vom Client gesendete Anforderung gültig ist (DELETE mySite / entity / 123 ) und die zu löschende Entität nicht vorhanden ist.
—
Martin
@Martin: In diesem Fall sollte der Dienst ein HTTP 404 zurückgeben. Genau genommen ist eine DELETE- oder eine GET-Anforderung für eine Ressource, die nicht vorhanden ist, keine "gültige" Anforderung - dh. Der Client sollte diese Anforderung nicht erneut versuchen, da sie niemals erfolgreich sein wird. Das HTTP-Protokoll definiert zwei Kategorien von Problemen - diejenigen mit einem 4xx-Statuscode, bei denen der Client die Anforderung ändern muss, bevor er sie erneut versucht, und diejenigen mit einem 5xx-Status Code, der angibt, dass der Dienst in Schwierigkeiten geraten ist und der Client dieselbe exakte Anforderung wiederholen sollte / könnte, ohne sie zu ändern.
—
Daniel Vassallo
@ JeffMartin Das mag vom Standpunkt des Benutzers aus so sein, aber was den Server betrifft, sollte der Server 404 zurückgeben, wenn die Ressource nicht existiert.
—
Randolpho
@Randolpho, bei Idempotenz geht es darum, dasselbe Ergebnis zu erzielen, unabhängig davon, ob Sie eine Operation einmal oder mehrmals aufrufen. Der Client fordert Sie auf, sicherzustellen, dass die Ressource gelöscht wird. Was ist der Vorteil der Rückgabe von 404? Warum muss es so oder so wissen? Jetzt muss die Client-Logik zwei separate Antwortcodes anstelle von einem verarbeiten.
—
Gili
@Gili: Vielleicht erklärt das Wiki es besser: Die Methoden PUT und DELETE sind als idempotent definiert. Beachten Sie, dass sich idempotence auf den Status des Systems bezieht, nachdem die Anforderung abgeschlossen wurde, also während der Aktion, die der Server ausführt (z. B. Löschen eines Datensatzes) ) oder der zurückgegebene Antwortcode kann bei nachfolgenden Anforderungen unterschiedlich sein. Der Systemstatus ist jedes Mal der gleiche.
—
Randolpho
Kurze Antwort: Für PUT und DELETE sollten Sie entweder 200 (OK) oder 204 (kein Inhalt) senden.
Lange Antwort: Hier ist ein vollständiges Entscheidungsdiagramm (zum Vergrößern klicken).
Das Diagramm ist erstaunlich. Gibt es eine Version mit höherer Auflösung zum Ausdrucken?
—
KiKi
Im Zusammenhang mit dem POST einer vorhandenen Ressource schlägt eine andere SO-Diskussion ( stackoverflow.com/questions/3825990/… ) vor, 409 Conflict oder 302 Found zu senden, anstatt den Inhalt anzuhängen .
—
Koppor
Ich bin gespannt, ob die Antworten 204 und 200 nach dem Löschen umgekehrt werden sollten und wenn sie so wie sie sind korrekt sind, warum? Gelöscht? -> Antwort enthält eine Entität? -> ja -> 204 Nein Inhalt; nein -> 200 OK
—
9.
Die aktualisierte Version des Bildes ist hier: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
—
zaius
Es fehlt PATCH.
—
Doremi
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 stimmt, 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.
Diese Antwort besteht fast ausschließlich aus zwei großen Anführungszeichen, aber es gibt keine Zuschreibung. Woher zitierst du?
—
Quentin
Ist 204 ein ordnungsgemäßer Status, um für eine PUT-Anforderung zurückzukehren, wenn der Status nicht effektiv geändert wird? Sie möchten beispielsweise einen Benutzer deaktivieren, der Benutzer ist jedoch bereits inaktiv.
—
О Г И І І
Die PUT-Anforderung ist idempotent, sodass Sie eine 204 zurückgeben können, da sich das Objekt im System geändert hat. PUT ist kein PATCH, daher sind Sie sich nicht sicher, welches Feld Sie ändern möchten. Sie können eine 501 - 502 zurücksenden, wenn Ihr Design wissen muss, ob das Objekt genau mit dem Objekt in der Anfrage übereinstimmt, aber ... es gefällt mir nicht wirklich. Ich bevorzuge 204 oder, wenn Sie möchten Deaktivieren Sie einen Benutzer, ohne weitere Felder zu ändern. Möglicherweise können Sie PATCH verwenden.
—
Alfonso Tienda
Ich würde HTTP 422 Unprocessable Entity hinzufügen. Es hilft, zwischen einer "fehlerhaften Anforderung" (z. B. fehlerhaftem XML / JSON) und ungültigen Feldwerten zu unterscheiden.
—
Vdboor
RFC 2616 beschreibt, welche Statuscodes verwendet werden sollen .
Und nein, es sind nicht immer 200.
Zusätzlich zu 200 und 204 könnte 205 (Inhalt zurücksetzen) eine gültige Antwort sein.
Der Server hat die Anforderung erfüllt und der Benutzeragent sollte die Dokumentansicht zurücksetzen, die das Senden der Anforderung verursacht hat ... [z. B.] Löschen der Form, in der die Eingabe erfolgt.
Da sich die Frage mit der Frage befasst, ob DELETE 200 vs 204 "zurückgeben" sollte, sollte berücksichtigt werden, dass einige Leute empfehlen, eine Entität mit Links zurückzugeben, sodass 200 bevorzugt wird .
"Anstatt 204 (kein Inhalt) zurückzugeben, sollte die API hilfreich sein und Orte vorschlagen, an die man gehen kann. In diesem Beispiel ist meines Erachtens ein offensichtlicher Link" 'irgendwo.com/container/' (minus 'Ressource') "- der Container, aus dem der Client gerade eine Ressource gelöscht hat. Vielleicht möchte der Client weitere Ressourcen löschen, sodass dies ein hilfreicher Link wäre. "
http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/
Wenn ein Client auf eine 204-Antwort stößt, kann er entweder aufgeben, zum Einstiegspunkt der API wechseln oder zur vorherigen Ressource zurückkehren, die er besucht hat. Keine der beiden Optionen ist besonders gut.
Persönlich würde ich nicht sagen, dass 204 falsch ist (der Autor auch nicht; er sagt "nervig"), weil gutes Caching auf der Client-Seite viele Vorteile hat. Am besten ist es, so oder so konsequent zu sein.
Hier ist ein Statuscode, den Sie für Ihre Art von Wissen kennen sollten.
1XX Informationsantworten
- 100 Weiter
- 101 Vermittlungsprotokolle
- 102 Verarbeitung
- 103 Frühe Hinweise
2XX Erfolg
- 200 OK
- 201 Erstellt
- 202 Akzeptiert
- 203 Nicht maßgebliche Informationen
- 204 Kein Inhalt
- 205 Inhalt zurücksetzen
- 206 Teilinhalt
- 207 Multi-Status
- 208 Bereits gemeldet
- 226 IM verwendet
3XX-Umleitung
- 300 Mehrfachauswahl
- 301 Dauerhaft verschoben
- 302 gefunden
- 303 Siehe Andere
- 304 Nicht geändert
- 305 Proxy verwenden
- 306 Proxy wechseln
- 307 Temporäre Weiterleitung
- 308 Permanente Weiterleitung
4XX Client-Fehler
- 400 schlechte Anfrage
- 401 Nicht autorisiert
- 402 Zahlung erforderlich
- 403 Verboten
- 404 Nicht gefunden
- 405 Methode nicht zulässig
- 406 Nicht akzeptabel
- 407 Proxy-Authentifizierung erforderlich
- 408 Zeitüberschreitung anfordern
- 409 Konflikt
- 410 weg
- 411 Länge erforderlich
- 412 Voraussetzung fehlgeschlagen
- 413 Nutzlast zu groß
- 414 URI zu lang
- 415 Nicht unterstützter Medientyp
- 416 Reichweite nicht zufriedenstellend
- 417 Erwartung fehlgeschlagen
- 418 Ich bin eine Teekanne
- 420 Methodenfehler
- 421 Fehlgeleitete Anfrage
- 422 Nicht verarbeitbare Entität
- 423 Gesperrt
- 424 Fehlgeschlagene Abhängigkeit
- 426 Upgrade erforderlich
- 428 Voraussetzung erforderlich
- 429 Zu viele Anfragen
- 431 Anforderungsheaderfelder zu groß
- 451 Aus rechtlichen Gründen nicht verfügbar
5XX Server Fehler
- 500 Interner Serverfehler
- 501 Nicht implementiert
- 502 Bad Gateway
- 503 Dienst nicht verfügbar
- 504 Gateway Timeout
- 505 HTTP-Version wird nicht unterstützt
- 506 Varient Auch verhandeln
- 507 Unzureichender Speicher
- 508 Schleife erkannt
- 510 Nicht erweitert
- 511 Netzwerkauthentifizierung erforderlich
Im Juni 2014 hat RFC7231 RFC2616 überholt. Wenn Sie REST über HTTP ausführen, beschreibt RFC7231 genau, welches Verhalten von GET, PUT, POST und DELETE erwartet wird
Wenn eine Ressource geändert wird, sollte der Antwortcode 200 („OK“) sein . Wenn sich der Ressourcenstatus so ändert, dass der URI in die Ressource geändert wird (z. B. wird ein Benutzerkonto umbenannt), lautet der Antwortcode 301 („Permanent verschoben“). und der Standortheader sollte den neuen URI bereitstellen.
Wenn ein Objekt gelöscht wird, wird der Antwortcode angezeigt 200 („OK“) sein.
Folgen Sie dem unten stehenden Link für weitere Details - Statuscode für Ruhe