it-swarm.com.de

HTTP-Statuscode zum Aktualisieren und Löschen?

Welchen Statuscode sollte ich für UPDATE (PUT) und DELETE (z. B. Produkt erfolgreich aktualisiert) festlegen?

1204
xpepermint

Für eine PUT Anfrage: HTTP 200 oder HTTP 204 sollte "Ressource erfolgreich aktualisiert" bedeuten.

Für eine LÖSCHE Anfrage: HTTP 200 oder HTTP 204 sollte "Ressource erfolgreich gelöscht" bedeuten. Es kann auch HTTP 202 zurückgegeben werden, was bedeutet, dass der Befehl vom Server akzeptiert und die "Ressource zum Löschen markiert" wurde.

PUT

Wenn eine vorhandene Ressource geändert wird, MÜSSEN die Antwortcodes 200 (OK) oder 204 (No Content) gesendet werden, um den erfolgreichen Abschluss der Anforderung anzuzeigen.

DELETE

Eine erfolgreiche Antwort MUSS 200 (OK) lauten, 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 ausgeführt wurde eine Einheit.

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

Quelle: Liste der HTTP-Statuscodes: 2xx Success

1869
Daniel Vassallo

Kurze Antwort: Für PUT und DELETE sollten Sie entweder 200 (OK) oder 204 (No Content) senden.

Lange Antwort: Hier ist ein komplettes Entscheidungsdiagramm (zum Vergrößern anklicken).

HTTP 1.1 decision diagram

Quelle: https://github.com/for-GET/http-decision-diagram

799
ЯegDwight

Hier sind einige Tipps:

DELETE

  • 2 (wenn Sie zusätzliche Daten in der Antwort senden möchten) oder 204 (empfohlen).

  • 202 Operation gelöscht wurde noch nicht festgeschrieben.

  • Wenn Sie nichts löschen möchten, verwenden Sie 204 oder 404 (Die DELETE-Operation ist idempotent. Löschen Sie eine Bereits gelöschtes Element ist Vorgang erfolgreich , daher können Sie 204 zurückgeben, aber es ist wahr, dass idempotent nicht unbedingt dasselbe impliziert Antwort)

Andere Fehler:

  • 4 Bad Request (Falsche Syntax oder eine falsche Abfrage ist seltsam aber möglich).
  • 401 Nicht autorisierte Authentifizierung fehlgeschlagen
  • 4 Verboten : Autorisierungsfehler oder ungültige Anwendungs-ID.
  • 405 Nicht erlaubt . Sicher.
  • 409 Ressourcenkonflikt kann in komplexen Systemen möglich sein.
  • Und 501, 502 im Fehlerfall.

PUT

Wenn Sie ein Element einer Sammlung aktualisieren

  • 200/204 mit den gleichen Gründen wie DELETE oben.
  • 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.

  • 4 Bad Request (Falsche Syntax oder falsche Abfrage häufiger als bei DELETE).

  • 401 Nicht autorisiert
  • 4 Verboten : Authentifizierungsfehler oder ungültige Anwendungs-ID.
  • 405 Nicht erlaubt . Sicher.
  • 409 Ressourcenkonflikt kann in komplexen Systemen wie in DELETE möglich sein.
  • 422 Nicht verarbeitbare Entität Es hilft, zwischen einer "schlechten Anfrage" (z. B. fehlerhaftem XML/JSON) und ungültigen Feldwerten zu unterscheiden
  • Und 501, 502 im Fehlerfall.
132
Alfonso Tienda

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.

9
pje

Da sich die Frage damit befasst, ob DELETE "should" 2 vs 204 zurückgeben soll, ist zu bedenken, dass einige Leute die Rückgabe einer Entität mit Links empfehlen also ist die Präferenz für 2.

"Anstatt 204 (No Content) zurückzugeben, sollte die API hilfreich sein und Orte vorschlagen, an die man gehen kann. In diesem Beispiel sollte ein offensichtlicher Link angegeben werden:" 'somewhere.com/container/' ( minus 'resource') "- 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 Antwort 204 stößt, kann er entweder aufgeben, zum Einstiegspunkt der API gehen oder zur vorherigen Ressource zurückkehren, die er besucht hat. Keine Option 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.

6
KCD

Im Juni 2014 RFC7231 veraltet RFC2616. Wenn Sie REST über HTTP ausführen, beschreibt RFC7231 genau, welches Verhalten von GET, PUT, POST und DELETE erwartet wird

3
Ivan

Hier ist ein Statuscode, den Sie für Ihre Kenntnisse kennen sollten.

1XX Informationsantworten

  • 1 Weiter
  • 101 Umschaltprotokolle
  • 102 Verarbeitung
  • 1 Frühe Hinweise

2XX Erfolg

  • 2OK
  • 201 Erstellt
  • 202 Akzeptiert
  • 2 Nicht maßgebliche Information
  • 204 Kein Inhalt
  • 205 Inhalt zurücksetzen
  • 206 Teilinhalt
  • 207 Multi-Status
  • 208 Bereits gemeldet
  • 226 IM verwendet

3XX Umleitung

  • Mehrfachauswahl
  • 1 Permanent verschoben
  • 2 Gefunden
  • Andere anzeigen
  • 4 Nicht geändert
  • 5 Proxy verwenden
  • 6 Proxy wechseln
  • 7 Temporäre Umleitung
  • 8 Permanente Weiterleitung

4XX Client-Fehler

  • 4 Bad Request
  • 401 Nicht autorisiert
  • 402 Zahlung erforderlich
  • 4 Verboten
  • 404 Nicht gefunden
  • 405 Methode nicht zulässig
  • 406 Nicht akzeptabel
  • 407 Proxy-Authentifizierung erforderlich
  • 408 Anforderungs-Timeout
  • 409 Konflikt
  • 41 gegangen
  • 411 Erforderliche Länge
  • 412 Voraussetzung fehlgeschlagen
  • 41 Nutzlast zu groß
  • 414 URI zu lang
  • 415 Nicht unterstützter Medientyp
  • 416 Bereich nicht zufriedenstellend
  • 417 Erwartung gescheitert
  • 418 Ich bin eine Teekanne
  • 42 Methodenfehler
  • 421 Fehlgeleitete Anfrage
  • 422 Nicht verarbeitbare Entität
  • 42 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

  • 5 Interner Serverfehler
  • 501 Nicht implementiert
  • 502 Bad Gateway
  • 5 Dienst nicht verfügbar
  • 504 Gateway Timeout
  • 505 HTTP-Version nicht unterstützt
  • 506 Varient Auch verhandeln
  • 507 Unzureichender Speicherplatz
  • 508 Schleife erkannt
  • 51 Nicht erweitert
  • 511 Netzwerkauthentifizierung erforderlich
1
Prince

Hypertext Transfer Protocol (HTTP/1.1): Semantik und Inhalt

Kurz erklärt Weitere Informationen zu Statuscodes

0
Ahamed Rasheed