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

204 ist besser geeignet. Vor allem, wenn Sie ein Warnsystem haben, um sicherzustellen, dass Ihre Website sicher ist, würde 404 in diesem Fall Verwirrung stiften, weil Sie nicht wissen, ob es sich bei einigen 404-Meldungen um Backend-Fehler oder normale Anfragen mit leerer Antwort handelt.

Answer 2

404 wäre für jeden Kunden sehr verwirrend, wenn Sie zurückkehren, nur weil keine Daten in der Antwort vorhanden sind.

Für mich ist der Antwortcode 200 mit einem leeren Textkörper ausreichend, um zu verstehen, dass alles perfekt ist, aber keine Daten vorhanden sind, die den Anforderungen entsprechen.

Answer 3

Wie bereits von vielen erwähnt, ist 404 irreführend und erlaubt es dem Client nicht zu unterscheiden, ob die angeforderte URL nicht existiert oder ob die angeforderte URL die angeforderte Ressource nicht abrufen kann.

Es wird erwartet, dass der Status 200 Ressourcendaten enthält - daher ist er nicht die richtige Wahl. Der Status 204 bedeutet etwas ganz anderes und sollte nicht als Antwort auf GET-Anfragen verwendet werden.

Alle anderen bestehenden Status sind aus dem einen oder anderen Grund nicht anwendbar.

Ich habe gesehen, dass dieses Thema immer wieder an verschiedenen Stellen diskutiert wird. Für mich ist es schmerzlich offensichtlich, dass ein spezieller Erfolgsstatus erforderlich ist, um die Verwirrung um dieses Thema zu beseitigen. Etwas wie " 209 - Keine Ressource zum Anzeigen".

Es wird ein 2xx-Status sein, weil das Nichtfinden einer ID nicht als Client-Fehler betrachtet werden sollte (wenn die Clients alles wüssten, was in der DB des Servers steht, müssten sie den Server nicht fragen, oder?). Dieser spezielle Status wird alle Probleme lösen, die bei der Verwendung anderer Status diskutiert werden.

Die einzige Frage ist: Wie kann ich RFC dazu bringen, dies als Standard zu akzeptieren?

Answer 4

Ich glaube nicht, dass 404 die richtige Antwort ist.

Wenn Sie 404 verwenden, woher wissen Sie dann, dass die API nicht gefunden wurde oder dass der Datensatz in Ihrer Datenbank nicht gefunden wurde?

Nach Ihrer Beschreibung würde ich 200 OK verwenden, da Ihre API die gesamte Logik ohne jegliche Probleme ausgeführt hat. Sie konnte den Datensatz nur nicht in der Datenbank finden. Es ist also weder ein API-Problem noch ein Datenbankproblem, sondern Ihr Problem: Sie denken, dass der Datensatz existiert, aber das tut er nicht. Aus diesem Grund wurde die API erfolgreich ausgeführt, die Datenbankabfrage wurde erfolgreich ausgeführt, aber es wurde nichts gefunden und zurückgegeben.

Aus diesem Grund würde ich in diesem Fall Folgendes verwenden

200 OK

mit leeren Antworten wie [] für Arrays oder {} für Objekte.

Answer 5

Kodierung des Antwortinhalts mit einer gemeinsamen Aufzählung, die es dem Kunden ermöglicht, die Logik entsprechend einzuschalten und zu forken. Ich bin mir nicht sicher, wie Ihr Client den Unterschied zwischen "Daten nicht gefunden" 404 und "Webressource nicht gefunden" 404 erkennen kann. Sie wollen nicht, dass jemand zum Benutzer Z /9 und der Client tut so, als sei die Anfrage gültig, aber es wurden keine Daten zurückgegeben.