Was ist der richtige REST-Antwortcode für eine gültige Anfrage, aber leere Daten?

Question

Sie führen zum Beispiel eine GET-Anfrage für users/9 aber es gibt keinen Benutzer mit der ID #9. Welches ist der beste Antwortcode?

• 200 OK
• 202 Angenommen
• 204 Ohne Inhalt
• 400 Schlechte Anfrage
• 404 nicht gefunden

Answer 1

Ich bin entschieden gegen 404 und für 204 oder 200 mit leeren Daten. Oder man sollte zumindest eine Antwortentität mit dem 404 verwenden.

Die Anfrage wurde empfangen und ordnungsgemäß verarbeitet - sie hat Anwendungscode auf dem Server ausgelöst, der Client hat möglicherweise keinen Fehler gemacht, und daher ist die gesamte Klasse der Client-Fehlercodes (4xx) möglicherweise nicht passend.

Noch wichtiger ist, dass 404 aus einer Reihe von technischen Gründen auftreten kann. Z.B. wenn die Anwendung auf dem Server vorübergehend deaktiviert oder deinstalliert wurde, wenn es Probleme mit der Proxy-Verbindung gibt und so weiter.

Sicher, es gibt die Fehlerklasse 5xx für solche Fälle, aber in der Realität haben die betroffenen Middleware-Komponenten oft keine Möglichkeit zu wissen, dass der Fehler auf ihrer Seite liegt und gehen dann einfach davon aus, dass der Fehler auf der Client-Seite liegt und antworten dann mit 404 statt 500/503.

Daher kann der Kunde anhand des Statuscodes allein nicht unterscheiden zwischen einem 404, der bedeutet: "Das, wonach Sie suchen, existiert nicht", und einem 404, der bedeutet: "Da stimmt etwas nicht, melden Sie diesen Fehler dem Ops-Team".

Das kann fatal sein: Stellen Sie sich eine Buchhaltung in Ihrem Unternehmen vor, die alle Mitarbeiter auflistet, denen ein Jahresbonus zusteht. Leider wird bei einem einzigen Aufruf eine 404 zurückgegeben. Bedeutet das, dass niemandem ein Bonus zusteht, oder dass die Anwendung derzeit wegen einer Neuinstallation außer Betrieb ist und der 404 von dem Tomcat kommt, in dem sie installiert werden soll, anstatt von der Anwendung selbst? Diese beiden Szenarien ergeben denselben Statuscode, aber sie sind in ihrer Bedeutung grundlegend verschieden.

-> Für Anwendungen, die wissen müssen, dass eine angeforderte Ressource tatsächlich nicht existiert und nicht nur vorübergehend unerreichbar ist, ist 404 ohne Antwortentität daher so gut wie ein No-Go.

Außerdem reagieren viele Client-Frameworks auf einen 404-Code mit einer Ausnahme, ohne dass weitere Fragen gestellt werden. Dadurch ist der Client-Entwickler gezwungen, diese Ausnahme abzufangen, sie zu bewerten und dann auf dieser Grundlage zu entscheiden, ob sie als Fehler protokolliert werden soll, der z. B. von einer Überwachungskomponente aufgegriffen wird, oder ob sie ignoriert werden soll. Das scheint mir auch nicht schön zu sein.

Der Vorteil von 404 gegenüber 204 ist, dass eine Antwortentität zurückgegeben werden kann, die einige Informationen darüber enthält, warum die angeforderte Ressource nicht gefunden wurde. Wenn dies jedoch wirklich relevant ist, kann man auch eine 200 OK-Antwort in Betracht ziehen und das System so gestalten, dass es Fehlerantworten in den Nutzdaten zulässt. Alternativ könnte man den Payload der 404-Antwort nutzen, um strukturierte Informationen an den Aufrufer zurückzugeben. Wenn er z. B. eine HTML-Seite anstelle von XML oder JSON erhält, die er parsen kann, dann ist das ein guter Indikator dafür, dass etwas Technisches schief gelaufen ist, und nicht eine "kein Ergebnis"-Antwort, die aus Sicht des Anrufers gültig sein kann. Man könnte dafür auch einen HTTP-Antwort-Header verwenden.

Dennoch würde ich eine 204 oder 200 mit leerer Rückmeldung vorziehen. Auf diese Weise wird der Status der technischen Ausführung der Anfrage von dem logischen Ergebnis der Anfrage getrennt. 2xx bedeutet "technische Ausführung ok, das ist das Ergebnis, kümmern Sie sich darum".

Ich denke, in den meisten Fällen sollte es dem Kunden überlassen bleiben, zu entscheiden, ob ein leeres Ergebnis akzeptabel ist oder nicht. Durch die Rückgabe von 404 ohne Antwortentität trotz korrekter technischer Ausführung kann der Kunde entscheiden, Fälle als Fehler zu betrachten, die einfach keine Fehler sind.

Eine andere Perspektive: Aus betrieblicher Sicht kann eine 404 problematisch sein. Da er eher auf ein Konnektivitäts-/Middleware-Problem als auf eine gültige Service-Antwort hinweisen kann, möchte ich keine schwankende Anzahl "gültiger" 404 in meinen Metriken/Anzeigen, hinter denen sich echte technische Probleme verbergen könnten (z. B. ein falsch konfigurierter Proxy irgendwo im Anfrage-Routing), die untersucht und behoben werden sollten. Dies wird noch dadurch verschlimmert, dass einige APIs sogar 404 statt 401/403 verwenden (z. B. gitlab), um die Information zu verbergen, dass die Anfrage-URI zwar gültig gewesen wäre, der Anfrage aber die Berechtigung zum Zugriff fehlte. Auch in diesem Fall sollte ein 404 als technischer Fehler und nicht als gültiges "resource not found"-Ergebnis behandelt werden.

Edit: Wow, das hat eine Menge Kontroversen ausgelöst. Hier ist ein weiteres Argument gegen 404: Streng genommen bedeutet 404 aus Sicht der HTTP-Spezifikation (RFC7231) nicht einmal, dass eine Ressource nicht existiert. Es bedeutet nur, dass der Server keine aktuelle Repräsentation der angeforderten Ressource zur Verfügung hat, und diese kann sogar nur vorübergehend sein. Streng nach den HTTP-Spezifikationen ist 404 also von Natur aus unzuverlässig in Bezug auf die Nichtexistenz einer angeforderten Sache. Wenn Sie mitteilen wollen, dass die angeforderte Sache definitiv nicht existiert, sollten Sie nicht 404 verwenden.

Answer 2

TL;DR: Verwendung 404

見る Dieser Blog . Er erklärt es sehr gut.

Zusammenfassung der Kommentare in diesem Blog zu 204 :

1. 204 No Content ist als Antwortcode für einen Browser nicht sonderlich nützlich (obwohl er laut HTTP-Spezifikation von den Browsern als Antwortcode für "Don't change the view" verstanden werden muss).
2. 204 No Content es jedoch sehr nützlich für Ajax-Webdienste, die einen Erfolg anzeigen möchten, ohne etwas zurückgeben zu müssen. (Besonders in Fällen wie DELETE o POST s, die keine Rückmeldung erfordern).

Die Antwort auf Ihre Frage lautet daher: Verwendung 404 in Ihrem Fall. 204 ist ein spezieller Antwortcode, den man nicht oft an einen Browser zurückgeben sollte, wenn man eine GET .

Die anderen Antwortcodes sind noch weniger geeignet als 204 y 404 :

1. 200 sollte mit dem Body des erfolgreich abgeholten Textes zurückgegeben werden. Nicht geeignet, wenn die Entität, die Sie abrufen, nicht vorhanden ist.
2. 202 wird verwendet, wenn der Server mit der Arbeit an einem Objekt begonnen hat, das Objekt aber noch nicht vollständig fertig ist. Das ist hier sicherlich nicht der Fall. Sie haben weder mit der Konstruktion von user 9 begonnen, noch werden Sie damit beginnen, als Antwort auf eine GET Anfrage. Das verstößt gegen eine ganze Reihe von Regeln.
3. 400 wird als Reaktion auf eine schlecht formatierte HTTP-Anfrage verwendet (z. B. fehlerhafte HTTP-Header, falsch angeordnete Segmente usw.). Dies wird mit ziemlicher Sicherheit von dem von Ihnen verwendeten Framework gehandhabt werden. Sie sollten sich damit nicht befassen müssen, es sei denn, Sie schreiben Ihren eigenen Server von Grund auf neu. bearbeiten : Neuere RFCs erlauben nun die Verwendung von 400 für semantisch ungültige Anfragen.

Wikipedia's Beschreibung der HTTP-Statuscodes sind besonders hilfreich. Sie können auch die Definitionen einsehen im HTTP/1.1 RFC2616 Dokument unter www.w3.org

Answer 3

Zuerst dachte ich, dass eine 204 sinnvoll wäre, aber nach den Diskussionen glaube ich, dass 404 die einzig richtige Antwort ist. Betrachten Sie die folgenden Daten:

Benutzer: Johannes, Peter

METHOD  URL                      STATUS  RESPONSE
GET     /users                   200     [John, Peter]
GET     /users/john              200     John
GET     /unknown-url-egaer       404     Not Found
GET     /users/kyle              404     User Not found
GET     /users?name=kyle`        200     []
DELETE  /users/john              204     No Content

Einige Hintergrundinformationen:

1. die Suche liefert ein Array, es gab nur keine Treffer, aber es hat Inhalt: ein leeres Array .

2. 404 ist natürlich am besten bekannt für URLs, die nicht unterstützt werden von der angeforderte Server nicht unterstützt, aber eine fehlende Ressource ist im Grunde dasselbe.
   Auch wenn /users/:name wird abgeglichen mit users/kyle der Benutzer Kyle ist keine verfügbare Ressource, so dass eine 404 immer noch gilt. Es handelt sich nicht um eine Suchanfrage, es ist eine direkter Verweis über eine dynamische URL 404 ist es also.

3. Nach den Vorschlägen in den Kommentaren ist die Anpassung der 404-Meldung eine weitere Möglichkeit, dem API-Kunden zu helfen, noch besser zwischen völlig unbekannten Routen und fehlenden Entitäten zu unterscheiden.

Wie auch immer, meine zwei Cents :)

Answer 4

Wenn erwartet wird, dass die Ressource existiert, aber möglicherweise leer ist, wäre es einfacher, ein 200 OK mit einer Darstellung zu erhalten, die angibt, dass die Ressource leer ist.

Ich möchte also lieber, dass /things ein 200 OK mit {"Items": []} als ein 204 mit gar nichts, denn auf diese Weise kann eine Sammlung mit 0 Elementen genauso behandelt werden wie eine Sammlung mit einem oder mehreren Elementen darin.

Ich würde die 204 No Content nur für PUTs und DELETEs belassen, wo es vielleicht wirklich keine sinnvolle Darstellung gibt.

Für den Fall, dass /thing/9 wirklich nicht existiert, ist ein 404 angemessen.

Answer 5

Bei früheren Projekten habe ich 404 verwendet. Wenn es keinen Benutzer 9 gibt, dann wurde das Objekt nicht gefunden. Daher ist 404 Not Found angemessen.

Wenn ein Objekt vorhanden ist, aber keine Daten vorhanden sind, wäre 204 Kein Inhalt angemessen. Ich denke, in Ihrem Fall hat das Objekt pas existieren jedoch.