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

Nach der Suche in Frage, sollten Sie nicht verwenden 404 Warum?

Basierend auf RFC 7231 der korrekte Statuscode lautet 204

In den obigen Antworten ist mir 1 kleines Missverständnis aufgefallen:

1.- die Ressource ist: /users

2.- /users/8 ist nicht die Ressource, sondern: die Ressource /users mit Routenparameter 8 Der Verbraucher kann es vielleicht nicht bemerken und kennt den Unterschied nicht, aber der Verleger weiß es und muss es wissen!... also muss er den Verbrauchern eine korrekte Antwort geben.

also:

Basierend auf dem RFC: 404 ist falsch, weil die Ressourcen /users gefunden wird, aber die Logik, die mit dem Parameter 8 hat keine gefunden content als Antwort zurückgeben, so dass die richtige Antwort lautet: 204

Der wichtigste Punkt ist hier: 404 nicht einmal die Ressource zur Verarbeitung der internen Logik gefunden wurde

204 ist ein: Ich habe die Ressource gefunden, die Logik wurde ausgeführt, aber ich habe keine Daten anhand der von Ihnen im Routenparameter angegebenen Kriterien gefunden, so dass ich Ihnen nichts zurückgeben kann. Es tut mir leid, überprüfen Sie Ihre Kriterien und rufen Sie mich erneut an.

200 Ich habe die Ressource gefunden, die Logik wurde ausgeführt (auch wenn ich nicht gezwungen bin, etwas zurückzugeben), und Sie können sie nach Belieben verwenden.

205 (die beste Option einer GET-Antwort) Ich habe die Ressource gefunden, die Logik wurde ausgeführt, ich habe einige Inhalte für Sie, verwenden Sie sie gut, ach ja, wenn Sie dies in einer Ansicht teilen werden, aktualisieren Sie bitte die Ansicht, um sie anzuzeigen.

Ich hoffe, es hilft.

Answer 2

TL;DR:

• Wenn kein Benutzer gefunden wird unter /users/9 sollten Sie eine 404 zurückgeben.
• Wenn kein Benutzer gefunden wird unter /users?id=9 sollten Sie eine 204 zurückgeben.

Lange Version:

Nachdem ich meine eigene Verwendung dieser Statuscodes und die Beispiele in diesem Beitrag überprüft habe, würde ich sagen, dass 404 die angemessene Antwort ist, wenn User #9 bei der Url von /users/9 .

In meinem heutigen System sind unsere Application Insights-Protokolle mit Hunderten von protokollierten 404-Fehlern gefüllt, die unsere Protokolle verunreinigen, weil wir beschlossen haben, 404-Fehler zurückzugeben, wenn /users/9 keine korrelierenden Daten hatten. Dies bedeutet jedoch nicht, dass unser Ansatz bei der Erstellung unserer Daten falsch war. Antworten Vielmehr würde ich vorschlagen, dass es bedeutet, dass unser Ansatz bei der Erstellung unserer Datenbank falsch war. Weiterleitung .

Wenn Sie erwarten, dass ein Endpunkt viel Datenverkehr erhält, und sich Sorgen machen, dass zu viele 404-Fehler protokolliert werden, sollten Sie Ihr Routing so ändern, dass es mit dem gewünschten Statuscode übereinstimmt, und nicht einen Statuscode erzwingen, der unangemessen verwendet wird.

Wir haben inzwischen beschlossen, 2 Änderungen an unserem Code vorzunehmen:

1. Ändern Sie unsere Route zur Arbeit durch die Erwartung /users?id=9
2. Ändern Sie unseren Fehlercode in 204, damit die 404-Fehler nicht unsere AI-Protokolle füllen.

Letztendlich muss der API-Architekt verstehen, wie seine API verwendet wird und welche Art von Routing für diesen Anwendungsfall geeignet ist.

Ich glaube, dass im Fall von /users/9 Die Ressource, die Sie anfordern, ist der Benutzer selbst, Benutzer Nr. 9; Sie bitten den Server, mit einem Objekt zu antworten, das als "9" identifiziert wird und zufällig in einem Pfad existiert, der das Wort "user" enthält. Wenn dieses Objekt nicht gefunden wurde, sollten Sie eine 404 erhalten.

Wenn Sie jedoch /users?id=9 Ich habe das Gefühl, dass die Ressource, die Sie anfordern, der Users-Controller ist, aber auch ein bisschen spezifischer ist, so dass er nicht eine vollständige Liste aller Benutzer zurückgibt. Sie bitten den Server, mit einem bestimmten Benutzer zu antworten, der durch eine im Abfrage-String definierte ID-Nummer identifiziert werden kann. Wenn also keine Daten gefunden wurden, macht es für mich Sinn, dass eine 204 anwendbar ist, denn selbst wenn keine Daten gefunden wurden, wurde der Controller gefunden.

Mit dem Query-String-Ansatz wird auch etwas erreicht, das meiner Meinung nach nicht nur den API-Entwicklern, sondern auch den Client-Entwicklern hilft (insbesondere Nachwuchsentwicklern oder zukünftigen Entwicklern, die diesen Code erben, oder Code, der ihn aufruft):

Jedem Beteiligten wird sofort klar, dass es sich bei 9 um eine ID und nicht um eine beliebige Zahl handelt. Dieser Punkt mag in einem so einfachen Beispiel überflüssig erscheinen, aber denken Sie an ein System, das GUIDs als Zeilen-IDs verwendet oder Ihnen erlaubt, Daten über den Namen einer Person abzurufen, oder sogar an ein System, das Informationen für bestimmte Postleitzahlen anstelle von Zeilen-IDs zurückgibt. Es wäre für alle beteiligten Entwickler nützlich, wenn sie auf einen Blick wüssten, ob es sich bei dem identifizierenden Parameter um einen Vor- oder Nachnamen, einen vollständigen Namen oder eine Postleitzahl anstelle einer ID handelt.

Answer 3

Nach Angaben von Microsoft: Rückgabetypen für Controller-Aktionen in ASP.NET Core Web API Wenn Sie fast bis ganz nach unten scrollen, finden Sie den folgenden Hinweis auf 404, wenn ein Objekt in der Datenbank nicht gefunden wurde. Hier wird vorgeschlagen, dass ein 404 für leere Daten angemessen ist.

Answer 4

Twitter verwendet 404 mit einer eigenen Fehlermeldung wie "Keine Daten gefunden".

Ref: https://developer.twitter.com/en/docs/basics/response-codes.html

Answer 5

Según w3 Ich glaube an Folgendes:

2xx:

Diese Klasse von Statuscodes zeigt an, dass die Anfrage des Kunden erfolgreich empfangen, verstanden und akzeptiert wurde.

4xx:

Der Statuscode der Klasse 4xx ist für Fälle vorgesehen, in denen der Client einen Fehler gemacht zu haben scheint.

Ersucht ein Kunde um /users und es hat Benutzer aufzulisten, würde der Antwortcode lauten 200 OK (die Client-Anfrage war gültig).

Ersucht ein Kunde um /users und es hat keine Daten, wäre der Antwortcode immer noch 200 OK .
Die angefragte Entität/Ressource ist eine Liste der Benutzer existiert die Liste, nur ohne Benutzer (ein 204 No Content könnte verwendet werden, wenn eine leere Antwort gegeben wird, obwohl ich denke, dass eine leere Liste [] wäre besser).
Die Client-Anfrage war gültig, und die Ressource existiert, so dass ein 4xx-Antwortcode hier keinen Sinn machen würde.

Andererseits, wenn ein Kunde um eine /users/9 und dieser Benutzer nicht existiert, hat der Client einen Fehler gemacht, indem er nach einer Ressource gefragt hat, die nicht existiert, ein Benutzer . In diesem Fall ist es sinnvoll, mit einer 404 Not Found .