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

Sie führen beispielsweise eine GET-Anforderung für aus users/9, es gibt jedoch keinen Benutzer mit der ID 9. Welches ist der beste Antwortcode?

• 200 OK
• 202 Akzeptiert
• 204 Kein Inhalt
• 400 schlechte Anfrage
• 404 Nicht gefunden

TL; DR: Verwenden 404

Siehe diesen Blog . Es erklärt es sehr gut.

Zusammenfassung der Kommentare des Blogs zu 204:

1. 204 No Content ist als Antwortcode für einen Browser nicht besonders nützlich (obwohl Browser ihn gemäß der HTTP-Spezifikation als Antwortcode "Ansicht nicht ändern" verstehen müssen).
2. 204 No Content ist jedoch sehr nützlich für Ajax-Webdienste, die möglicherweise Erfolg anzeigen möchten, ohne etwas zurückgeben zu müssen. (Besonders in Fällen wie DELETEoder POSTs, die kein Feedback erfordern).

Die Antwort auf Ihre Frage lautet daher "Verwendung 404in Ihrem Fall". 204ist ein spezialisierter Antwortcode, den Sie als Antwort auf a nicht oft an einen Browser zurückgeben sollten GET.

Die anderen Antwortcodes, die noch weniger geeignet sind als 204und 404:

1. 200sollte mit dem Körper von allem zurückgegeben werden, was Sie erfolgreich abgerufen haben. Nicht geeignet, wenn die Entität, die Sie abrufen, nicht vorhanden ist.
2. 202wird verwendet, wenn der Server mit der Arbeit an einem Objekt begonnen hat, das Objekt jedoch noch nicht vollständig bereit ist. Sicher nicht der Fall hier. Sie haben noch nicht mit der Erstellung von Benutzer 9 als Antwort auf eine GETAnfrage begonnen und werden auch nicht damit beginnen . Das verstößt gegen alle möglichen Regeln.
3. 400wird als Antwort auf eine schlecht formatierte HTTP-Anforderung verwendet (z. B. fehlerhafte http-Header, falsch geordnete Segmente usw.). Dies wird mit ziemlicher Sicherheit von jedem Framework erledigt, das Sie verwenden. Sie sollten sich nicht damit befassen müssen, es sei denn, Sie schreiben Ihren eigenen Server von Grund auf neu. Bearbeiten : Neuere RFCs ermöglichen jetzt die Verwendung von 400 für semantisch ungültige Anforderungen.

Besonders hilfreich ist die Beschreibung der HTTP-Statuscodes durch Wikipedia . Sie können die Definitionen auch im HTTP / 1.1 RFC2616-Dokument unter www.w3.org sehen

Ich lehne 404 mit leeren Daten entschieden zugunsten von 204 oder 200 ab. Oder zumindest sollte man eine Antwortentität mit dem 404 verwenden.

Die Anfrage wurde empfangen und ordnungsgemäß verarbeitet - sie hat Anwendungscode auf dem Server ausgelöst, daher kann man nicht wirklich sagen, dass es sich um einen Clientfehler handelt und daher die gesamte Klasse der Clientfehlercodes (4xx) nicht passt.

Noch wichtiger ist, dass 404 aus einer Reihe technischer Gründe auftreten kann. ZB die Anwendung, die vorübergehend auf dem Server deaktiviert oder deinstalliert wird, Probleme mit der Proxy-Verbindung und so weiter. Daher kann der Client nicht zwischen einem 404, der "leere Ergebnismenge" bedeutet, und einem 404, der bedeutet, dass der Dienst nicht gefunden werden kann, versuchen Sie es später erneut, unterscheiden.

Dies kann fatal sein: Stellen Sie sich einen Buchhaltungsservice in Ihrem Unternehmen vor, in dem alle Mitarbeiter aufgelistet sind, für die ein jährlicher Bonus fällig ist. Leider wird beim einmaligen Aufruf eine 404 zurückgegeben. Bedeutet dies, dass niemand einen Bonus erhalten muss oder dass die Anwendung derzeit für eine neue Bereitstellung nicht verfügbar ist?

-> Für Anwendungen, die sich um die Qualität ihrer Daten kümmern, ist 404 ohne Antwortentität daher so gut wie ein No-Go.

Außerdem reagieren viele Client-Frameworks auf einen 404, indem sie eine Ausnahme auslösen, ohne dass weitere Fragen gestellt werden. Dies zwingt den Client-Entwickler, diese Ausnahme abzufangen, sie auszuwerten und dann basierend darauf zu entscheiden, ob sie als Fehler protokolliert werden soll, der beispielsweise von einer Überwachungskomponente erkannt wird, oder ob sie ignoriert werden soll. Das kommt mir auch nicht schön vor.

Der Vorteil von 404 gegenüber 204 besteht darin, dass eine Antwortentität zurückgegeben werden kann, die möglicherweise Informationen darüber enthält, warum die angeforderte Ressource nicht gefunden wurde. Wenn dies jedoch wirklich relevant ist, kann auch die Verwendung einer 200-OK-Antwort in Betracht gezogen und das System so gestaltet werden, dass Fehlerantworten in den Nutzdaten berücksichtigt werden. Alternativ könnte man die Nutzlast der 404-Antwort verwenden, um strukturierte Informationen an den Anrufer zurückzugeben. Wenn er z. B. eine HTML-Seite anstelle von XML oder JSON erhält, die er analysieren kann, ist dies ein guter Indikator dafür, dass ein technischer Fehler aufgetreten ist, anstatt einer Antwort "kein Ergebnis", die aus Sicht des Anrufers gültig sein kann. Oder man könnte dafür einen HTTP-Antwortheader verwenden.

Trotzdem würde ich eine 204 oder 200 mit leerer Antwort bevorzugen. Auf diese Weise wird der Status der technischen Ausführung der Anforderung vom logischen Ergebnis der Anforderung getrennt. 2xx bedeutet "technische Ausführung ok, das ist das Ergebnis, damit umgehen".

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 weitere schnelle Analogie: Die Rückgabe von 404 für "kein Ergebnis gefunden" entspricht dem Auslösen einer DatabaseConnectionException, wenn eine SQL-Abfrage keine Ergebnisse zurückgibt. Es kann die Arbeit erledigen, aber es gibt viele mögliche technische Ursachen, die dieselbe Ausnahme auslösen, die dann für ein gültiges Ergebnis gehalten würde.

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

Benutzer: John, Peter

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

Einige Hintergrundinformationen:

1. Die Suche gibt ein Array zurück, es hatte nur keine Übereinstimmungen, aber es hat Inhalt: ein leeres Array .

2. 404 ist natürlich am besten für URLs bekannt, die vom angeforderten Server nicht unterstützt werden, aber eine fehlende Ressource ist tatsächlich dieselbe.
   Obwohl /users/:namemit übereinstimmt users/kyle, ist der Benutzer Kyle keine verfügbare Ressource, sodass immer noch ein 404 gilt. Es ist keine Suchabfrage, es ist eine direkte Referenz durch eine dynamische URL , also ist es 404.

Wie auch immer, meine zwei Cent :)

Wenn erwartet wird, dass die Ressource vorhanden ist, sie aber möglicherweise leer ist, würde ich argumentieren, dass es möglicherweise einfacher ist, nur ein 200 OK mit einer Darstellung zu erhalten, die angibt, dass das Objekt leer ist.

Ich hätte also lieber / 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 mehr Artikel drin.

Ich würde nur den 204 No Content für PUTs und DELETEs belassen, wo es der Fall sein könnte, dass es wirklich keine nützliche Darstellung gibt.

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

In früheren Projekten habe ich 404 verwendet. Wenn kein Benutzer 9 vorhanden ist, wurde das Objekt nicht gefunden. Daher ist 404 Not Found angemessen.

Für Objekt existiert, aber es gibt keine Daten, 204 Kein Inhalt wäre angemessen. Ich denke in Ihrem Fall existiert das Objekt jedoch nicht .

Laut w3 post,

200 OK

Die Anfrage ist erfolgreich. Die mit der Antwort zurückgegebenen Informationen hängen von der in der Anforderung verwendeten Methode ab

202 Akzeptiert

Die Anforderung wurde zur Verarbeitung angenommen, die Verarbeitung wurde jedoch nicht abgeschlossen.

204 Kein Inhalt

Der Server hat die Anforderung erfüllt, muss jedoch keinen Entitätskörper zurückgeben und möchte möglicherweise aktualisierte Metainformationen zurückgeben.

400 schlechte Anfrage

Die Anforderung konnte vom Server aufgrund einer fehlerhaften Syntax nicht verstanden werden. Der Client sollte die Anfrage NICHT ohne Änderungen wiederholen

401 nicht Autorisiert

Die Anforderung erfordert eine Benutzerauthentifizierung. Die Antwort MUSS ein WWW-Authenticate-Headerfeld enthalten

404 Nicht gefunden

Der Server hat nichts gefunden, das mit dem Request-URI übereinstimmt. Es wird kein Hinweis darauf gegeben, ob der Zustand vorübergehend oder dauerhaft ist

Um zusammenzufassen oder zu vereinfachen,

2xx: Optionale Daten: Gut geformte URI: Kriterien sind nicht Teil der URI: Wenn die Kriterien optional sind, die in @RequestBody und @RequestParam angegeben werden können, sollte dies zu 2xx führen. Beispiel: Filtern nach Name / Status

4xx: Erwartete Daten: Nicht gut geformte URI: Kriterien sind Teil der URI: Wenn die Kriterien obligatorisch sind, die nur in @PathVariable angegeben werden können, sollte dies zu 4xx führen. Beispiel: Suche nach eindeutiger ID.

Also für die gestellte Situation: "Benutzer / 9" wäre 4xx (möglicherweise 404) Aber für "Benutzer? Name = Superman" sollte 2xx sein (möglicherweise 204)

Es werden zwei Fragen gestellt. Eine im Titel und eine im Beispiel. Ich denke, dies hat teilweise zu Streitigkeiten darüber geführt, welche Antwort angemessen ist.

Der Fragentitel fragt nach leeren Daten. Leere Daten sind immer noch Daten, aber nicht dasselbe wie keine Daten. Dies schlägt also vor, eine Ergebnismenge anzufordern, dh eine Liste, möglicherweise von /users. Wenn eine Liste leer ist, handelt es sich immer noch um eine Liste, daher ist eine 204 (kein Inhalt) am besten geeignet. Sie haben gerade nach einer Liste von Benutzern gefragt und eine erhalten, es ist einfach kein Inhalt vorhanden.

Das bereitgestellte Beispiel fragt stattdessen nach einem bestimmten Objekt, einem Benutzer /users/9. Wenn Benutzer Nr. 9 nicht gefunden wird, wird kein Benutzerobjekt zurückgegeben. Sie haben nach einer bestimmten Ressource (einem Benutzerobjekt) gefragt und diese nicht erhalten, weil sie nicht gefunden wurde. Daher ist ein 404 angemessen.

Ich denke, der Weg, dies herauszufinden, ist, wenn Sie die Antwort so verwenden können, wie Sie es erwarten würden, ohne eine bedingte Anweisung hinzuzufügen, dann verwenden Sie eine 204, andernfalls eine 404.

In meinen Beispielen kann ich eine leere Liste durchlaufen, ohne zu überprüfen, ob sie Inhalt enthält, aber ich kann keine Benutzerobjektdaten für ein Nullobjekt anzeigen, ohne etwas zu beschädigen oder eine Prüfung hinzuzufügen, um festzustellen, ob es Null ist.

Sie können natürlich ein Objekt mit dem Nullobjektmuster zurückgeben, wenn dies Ihren Anforderungen entspricht, aber dies ist eine Diskussion für einen anderen Thread.

Nachdem Sie in Frage gestellt haben, sollten Sie nicht verwenden, 404warum?

Basierend auf RFC 7231 lautet der korrekte Statuscode204

In den obigen Antworten habe ich 1 kleines Missverständnis bemerkt:

1.- Die Ressource ist: /users

2.- /users/8ist nicht die Ressource, dies ist: die Ressource /usersmit dem Routenparameter 8, der Verbraucher kann es möglicherweise nicht bemerken und kennt den Unterschied nicht, aber der Herausgeber weiß dies und muss es wissen! ... also muss er eine genaue Antwort für die Verbraucher zurückgeben. Zeitraum.

damit:

Basierend auf dem RFC: 404 ist falsch, weil die Ressourcen /usersgefunden wurden, aber die mit dem Parameter ausgeführte Logik 8hat keine gefunden content, die als Antwort zurückgegeben werden könnte. Die richtige Antwort lautet also:204

Der Hauptpunkt hier ist: Es wurde 404nicht einmal die Ressource gefunden, um die interne Logik zu verarbeiten

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

200: ok ich habe die Ressource gefunden, die Logik wurde ausgeführt (auch wenn ich nicht gezwungen bin, etwas zurückzugeben) nimm diese und benutze sie nach deinem Willen.

205: (die beste Option für eine GET-Antwort) Ich habe die Ressource gefunden, die Logik wurde ausgeführt. Ich habe einige Inhalte für Sie. Verwenden Sie sie gut. Übrigens, wenn Sie dies in einer Ansicht teilen möchten, aktualisieren Sie die Ansicht auf zeige es an.

Ich hoffe es hilft.

In den vorhandenen Antworten wird nicht näher darauf eingegangen, dass es einen Unterschied macht, ob Sie Pfadparameter oder Abfrageparameter verwenden.

• Bei Pfadparametern ist der Parameter Teil des Ressourcenpfads. In diesem Fall /users/9sollte die Antwort darin bestehen, 404dass diese Ressource nicht gefunden wurde. /users/9ist die Ressource und das Ergebnis ist unär oder ein Fehler, es existiert nicht. Dies ist keine Monade.
• Bei Abfrageparametern ist der Parameter nicht Teil des Ressourcenpfads. In diesem Fall /users?id=9sollte die Antwort darin bestehen, 204dass die Ressource /usersgefunden wurde, aber keine Daten zurückgeben konnte. Die Ressource ist /usersvorhanden und das Ergebnis ist nicht vorhanden. Sie ist auch dann vorhanden, wenn sie leer ist. Wenn ideindeutig zuzuordnen sind, dies ist eine Monade.

Ob Pfadparameter oder Abfrageparameter verwendet werden, hängt vom Anwendungsfall ab. Ich bevorzuge Pfadparameter für obligatorische, normative oder identifizierende Argumente und Abfrageparameter für optionale, nicht normative oder zuordnende Argumente (wie Paging, Sortiergebietsschema und so weiter). In einer REST-API würde ich wegen der möglichen Verschachtelung /users/9nicht /users?id=9besonders "untergeordnete Datensätze" abrufen /users/9/ssh-keys/0, um den ersten öffentlichen SSH-Schlüssel oder /users/9/address/2die dritte Postanschrift zu erhalten.

Ich bevorzuge die Verwendung von 404. Hier ist der Grund:

• Aufrufe für unäre (1 Ergebnis) und n-fache (n Ergebnisse) Methoden sollten nicht ohne Grund variieren. Ich möchte, wenn möglich, die gleichen Antwortcodes haben. Die Anzahl der erwarteten Ergebnisse ist natürlich ein Unterschied. Sie erwarten beispielsweise, dass der Körper ein Objekt (unär) oder ein Array von Objekten (n-ary) ist.
• Für n-ary würde ich ein Array zurückgeben, und falls es keine Ergebnisse gibt, würde ich keine Menge (kein Dokument) zurückgeben, ich würde eine leere Menge zurückgeben (leeres Dokument, wie leeres Array in JSON oder leeres Element in XML ). Das heißt, es ist immer noch 200, aber mit null Datensätzen. Es gibt keinen Grund, diese Informationen auf dem Draht außer im Körper anzubringen.
• 204ist wie eine voidMethode. Ich würde es nicht für verwenden GET, nur für POST, PUTund DELETE. Ich mache eine Ausnahme für den Fall, GETdass die Bezeichner Abfrageparameter und keine Pfadparameter sind.
• Nicht den Datensatz zu finden , ist wie NoSuchElementException, ArrayIndexOutOfBoundsExceptionoder so ähnlich, verursacht durch den Kunden eine ID verwenden , die nicht existiert, so, es ist ein Client - Fehler.
• Aus Code-Sicht 204bedeutet Abrufen einen zusätzlichen Zweig im Code, der vermieden werden könnte. Es verkompliziert den Client-Code und in einigen Fällen auch den Server-Code (abhängig davon, ob Sie Entitäts- / Modell-Monaden oder einfache Entitäten / Modelle verwenden. Ich empfehle dringend , sich von Entitäts- / Modell-Monaden fernzuhalten. Dies kann zu bösen Fehlern führen, wenn dies der Fall ist Von der Monade halten Sie eine Operation für erfolgreich und geben 200 oder 204 zurück, wenn Sie tatsächlich etwas anderes hätten zurückgeben sollen.
• Client-Code ist einfacher zu schreiben und zu verstehen, wenn 2xx bedeutet, dass der Server das getan hat, was der Client angefordert hat, und 4xx bedeutet, dass der Server nicht das getan hat, was der Client angefordert hat, und es die Schuld des Clients ist. Es ist die Schuld des Clients, dem Client nicht den Datensatz zu geben, den der Client über die ID angefordert hat, da der Client eine ID angefordert hat, die nicht vorhanden ist.

Last but not least: Konsistenz

• GET /users/9
• PUT /users/9 und DELETE /users/9

PUT /users/9und DELETE /users/9müssen 204bei erfolgreicher Aktualisierung oder Löschung bereits zurückkehren. Was sollten sie also zurückgeben, falls Benutzer 9 nicht existiert? Es macht keinen Sinn, dieselbe Situation je nach verwendeter HTTP-Methode als unterschiedliche Statuscodes darzustellen.

Außerdem kein normativer, sondern ein kultureller Grund: Wenn 204für das GET /users/9nächste, was im Projekt passieren wird, verwendet wird, ist jemand der Meinung, dass die Rückkehr 204für viele Methoden gut ist. Dies erschwert den Client-Code, da 2xxder Client jetzt nicht nur nach dem Body suchen und ihn dann dekodieren muss , sondern ihn auch spezifisch nach 204dem Body suchen und in diesem Fall überspringen muss. Bud, was macht der Kunde stattdessen? Ein leeres Array erstellen? Warum haben Sie das dann nicht auf dem Draht? Wenn der Client das leere Array erstellt, ist 204 eine Form der dummen Komprimierung. Wenn der Client nullstattdessen verwendet, wird eine ganz andere Dose Würmer geöffnet.

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

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

204 ist angemessener. Insbesondere wenn Sie über ein Warnsystem verfügen, um sicherzustellen, dass Ihre Website sicher ist, würde 404 in diesem Fall Verwirrung stiften, da Sie nicht wissen, dass einige 404-Warnungen Backend-Fehler oder normale Anforderungen sind, die Antwort jedoch leer ist.

Ich würde sagen, beides ist nicht wirklich angemessen. Wie bereits gesagt - z. B. von @anneb - denke ich auch, dass ein Teil der Probleme auf die Verwendung eines HTTP-Antwortcodes zum Transport eines Status in Bezug auf einen RESTful-Service zurückzuführen ist. Alles, was der REST-Service über seine eigene Verarbeitung zu sagen hat, sollte mittels REST-spezifischer Codes transportiert werden.

1

Ich würde argumentieren, dass der HTTP-Server, wenn er einen Dienst findet, der bereit ist, eine gesendete Anfrage zu beantworten, nicht mit einem HTTP 404 antworten sollte - am Ende wurde etwas vom Server gefunden - es sei denn, dies wird ausdrücklich von der Service, der die Anfrage verarbeitet.

Nehmen wir für einen Moment die folgende URL an : http://example.com/service/return/test.

• Fall A ist, dass der Server „einfach nach der Datei im Dateisystem sucht“. Wenn es nicht vorhanden ist, 404ist es richtig. Das Gleiche gilt, wenn ein Dienst aufgefordert wird, genau diese Datei zu liefern, und dieser Dienst ihm mitteilt, dass nichts von diesem Namen vorhanden ist.
• In Fall B arbeitet der Server nicht mit „echten“ Dateien, sondern die Anforderung wird von einem anderen Dienst verarbeitet - z. B. einem Templating-System. Hier kann der Server keinen Anspruch auf die Existenz der Ressource erheben, da er nichts darüber weiß (es sei denn, der Dienst, der sie verwaltet, teilt dies mit).

Ohne eine Antwort des Dienstes, die explizit ein anderes Verhalten erfordert, kann der HTTP-Server nur drei Dinge sagen:

• 503 wenn der Dienst, der die Anforderung verarbeiten soll, nicht ausgeführt wird oder nicht antwortet;
• 200 Andernfalls kann der HTTP-Server die Anforderung tatsächlich erfüllen - unabhängig davon, was der Dienst später sagt.
• 400oder 404um anzuzeigen, dass es keinen solchen Dienst gibt (im Gegensatz zu "existiert, aber offline") und nichts anderes gefunden wurde.

2

Um auf die vorliegende Frage zurückzukommen: Ich denke, der sauberste Ansatz wäre, überhaupt keinen anderen HTTP-Antwortcode als den zuvor genannten zu verwenden. Wenn der Dienst vorhanden ist und antwortet, sollte der HTTP-Code 200 sein. Die Antwort sollte den Status des vom Dienst zurückgegebenen Dienstes in einem separaten Header enthalten - hier kann der Dienst sagen

• REST:EMPTYzB wenn es gebeten wurde, nach etw. zu suchen und diese Forschung kehrte leer zurück;
• REST:NOT FOUNDwenn es speziell nach etw gefragt wurde. "ID-ähnlich" - sei es ein Dateiname oder eine Ressource nach ID oder Eintrag Nr. 24 usw. - und diese bestimmte Ressource wurde nicht gefunden (normalerweise wurde eine bestimmte Ressource angefordert und nicht gefunden);
• REST:INVALID Wenn ein Teil der Anfrage, die gesendet wurde, vom Dienst nicht erkannt wird.

(Beachten Sie, dass ich diesen absichtlich das Präfix „REST:“ vorangestellt habe, um die Tatsache zu kennzeichnen, dass diese zwar dieselben Werte oder Formulierungen wie HTTP-Antwortcodes haben können, aber völlig anders sind.)

3

Kehren wir zur obigen URL zurück und untersuchen Fall B, in dem der Dienst dem HTTP-Server anzeigt, dass er diese Anforderung nicht selbst verarbeitet, sondern an sie weiterleitet SERVICE. HTTP gibt nur das aus, von dem es zurückgegeben wird SERVICE, es weiß nichts über den return/testTeil, von dem es verarbeitet wird SERVICE. Wenn dieser Dienst ausgeführt wird, sollte HTTP zurückkehren, 200da es tatsächlich etwas gefunden hat , um die Anforderung zu verarbeiten.

Der von zurückgegebene Status SERVICE(und der, wie oben erwähnt, in einem separaten Header angezeigt werden soll) hängt davon ab, welche Aktion tatsächlich erwartet wird:

• Wenn Sie return/testnach einer bestimmten Ressource fragen: Wenn sie vorhanden ist, geben Sie sie mit dem Status zurück REST:FOUND. Wenn diese Ressource nicht vorhanden ist, geben Sie sie zurück REST:NOT FOUND. Dies könnte erweitert werden, um zurückzukehren, REST:GONEwenn wir wissen, dass es einmal existiert hat und nicht zurückkehren wird, undREST:MOVED wenn wir wissen, dass es Hollywood geworden ist
• Wenn dies return/testals such- oder filterähnliche Operation betrachtet wird: Wenn die Ergebnismenge leer ist, geben Sie eine leere Menge in dem angeforderten Typ und den Status von zurück REST:EMPTY. eine Reihe von Ergebnissen in dem angeforderten Typ und einen Status vonREST:SUCCESS
• Wenn dies return/testkeine Operation ist, die erkannt wird von SERVICE: return, REST:ERRORwenn es völlig falsch ist (z. B. ein Tippfehler retrun/test) oder REST:NOT IMPLEMENTEDfalls es für später geplant ist.

4

Diese Unterscheidung ist viel sauberer als das Vermischen der beiden verschiedenen Dinge. Dies erleichtert auch das Debuggen und die Verarbeitung, wenn überhaupt, nur geringfügig.

• Wenn ein HTTP 404 zurückgegeben wird, sagt mir der Server: "Ich habe keine Ahnung, wovon Sie sprechen." Während der REST-Teil meiner Anfrage vollkommen in Ordnung sein könnte, suche ich an den falschen Stellen nach par'Mach.
• Auf der anderen Seite sagen mir HTTP 200 und REST: ERR, dass ich den Dienst erhalten habe, aber bei meiner Anfrage an den Dienst etwas falsch gemacht habe.
• Von HTTP 200 und REST: EMPTY weiß ich, dass ich nichts falsch gemacht habe - richtiger Server, der Server hat den Dienst gefunden, richtige Anfrage an den Dienst - aber das Suchergebnis ist leer.

Zusammenfassung

Das Problem und die Diskussion ergeben sich aus der Tatsache, dass HTTP-Antwortcodes verwendet werden, um den Status eines Dienstes zu kennzeichnen, dessen Ergebnisse von HTTP bereitgestellt werden, oder um etw zu kennzeichnen. Das liegt nicht im Bereich des HTTP-Servers. Aufgrund dieser Diskrepanz kann die Frage nicht beantwortet werden und alle Meinungen werden viel diskutiert.

Der Status einer Anforderung, die von einem Dienst und nicht vom HTTP-Server verarbeitet wird, sollte WIRKLICH NICHT (RFC 6919) durch einen HTTP-Antwortcode angegeben werden. Der HTTP-Code SOLLTE (RFC 2119) nur Informationen enthalten, die der HTTP-Server aus seinem eigenen Bereich geben kann: nämlich, ob der Dienst gefunden wurde, um die Anforderung zu verarbeiten oder nicht.

Stattdessen sollte eine andere Methode verwendet werden, um einen Verbraucher über den Status der Anforderung an den Dienst zu informieren, der die Anforderung tatsächlich verarbeitet. Mein Vorschlag ist, dies über einen bestimmten Header zu tun. Im Idealfall folgen sowohl der Name des Headers als auch sein Inhalt einem Standard, der es den Verbrauchern erleichtert, mit diesen Antworten zu arbeiten.

Gemäß RFC7231 - Seite 59 ( https://tools.ietf.org/html/rfc7231#page-59 ) lautet die Definition der 404-Statuscode-Antwort:

6.5.4. 404 Nicht gefunden Der Statuscode 404 (Nicht gefunden) zeigt an, dass der Ursprungsserver keine aktuelle Darstellung für die Zielressource gefunden hat oder nicht bereit ist, anzugeben, dass eine vorhanden ist. Ein 404-Statuscode gibt nicht an, ob dieser Mangel an Repräsentation vorübergehend oder dauerhaft ist. Der Statuscode 410 (Gone) wird 404 vorgezogen, wenn der Ursprungsserver vermutlich durch konfigurierbare Mittel weiß, dass der Zustand wahrscheinlich dauerhaft ist. Eine 404-Antwort kann standardmäßig zwischengespeichert werden. dh sofern in der Methodendefinition oder in expliziten Cache-Steuerelementen nicht anders angegeben (siehe Abschnitt 4.2.2 von [RFC7234]).

Und die Hauptsache, die Zweifel aufkommen lässt, ist die Definition der Ressource im obigen Kontext. Nach demselben RFC (7231) lautet die Definition der Ressource:

Ressourcen: Das Ziel einer HTTP-Anforderung wird als "Ressource" bezeichnet. HTTP schränkt die Art einer Ressource nicht ein. Es definiert lediglich eine Schnittstelle, die zur Interaktion mit Ressourcen verwendet werden kann. Jede Ressource wird durch einen URI (Uniform Resource Identifier) ​​identifiziert, wie in Abschnitt 2.7 von [RFC7230] beschrieben. Wenn ein Client eine HTTP / 1.1-Anforderungsnachricht erstellt, sendet er den Ziel-URI in einer von verschiedenen Formen, wie in (Abschnitt 5.3 von [RFC7230]) definiert. Wenn eine Anforderung empfangen wird, rekonstruiert der Server einen effektiven Anforderungs-URI für die Zielressource (Abschnitt 5.5 von [RFC7230]). Ein Entwurfsziel von HTTP besteht darin, die Ressourcenidentifikation von der Anforderungssemantik zu trennen. Dies wird ermöglicht, indem die Anforderungssemantik in die Anforderungsmethode (Abschnitt 4) und einige anforderungsmodifizierende Headerfelder (Abschnitt 5) übertragen wird.

Meines Erachtens sollte der 404-Statuscode bei einer erfolgreichen GET-Anforderung mit leerem Ergebnis nicht verwendet werden (Beispiel: Eine Liste ohne Ergebnis für einen bestimmten Filter).

Solche Dinge können subjektiv sein und es gibt einige interessante und verschiedene solide Argumente auf beiden Seiten. Die Rückgabe eines 404 für fehlende Daten ist jedoch [meiner Meinung nach] nicht korrekt . Hier ist eine vereinfachte Beschreibung, um dies zu verdeutlichen:

• Anfrage: Kann ich bitte Daten haben?
• Ressource (API-Endpunkt): Ich werde diese Anfrage hier für Sie erhalten [sendet eine Antwort auf potenzielle Daten]

Es ist nichts kaputt gegangen, der Endpunkt wurde gefunden und die Tabelle und die Spalten wurden gefunden, sodass die Datenbank abgefragt und die Daten "erfolgreich" zurückgegeben wurden!

Nun - ob diese "erfolgreiche Antwort" Daten enthält oder nicht, spielt keine Rolle. Sie haben um eine Antwort auf "potenzielle" Daten gebeten, und diese Antwort mit "potenziellen" Daten wurde erfüllt. Null, leer usw. sind gültige Daten.

200 bedeutet nur, dass jede Anfrage, die wir gemacht haben, erfolgreich war. Ich fordere Daten an, mit HTTP / REST ist nichts schiefgegangen, und als Daten (wenn auch leer) zurückgegeben wurden, war meine "Datenanforderung" erfolgreich.

Geben Sie eine 200 zurück und lassen Sie den Anforderer mit leeren Daten umgehen, da jedes spezifische Szenario dies rechtfertigt!

Betrachten Sie dieses Beispiel:

• Anfrage: Tabelle "Verstöße" mit der Benutzer-ID 1234 abfragen
• Ressource (API-Endpunkt): Gibt eine Antwort zurück, aber die Daten sind leer

Diese leeren Daten sind vollständig gültig. Dies bedeutet, dass der Benutzer keine Verstöße hat. Dies ist eine 200, da alles gültig ist, wie ich dann tun kann:

Sie haben keine Verstöße, haben einen Blaubeermuffin!

Wenn Sie dies für einen 404 halten, was sagen Sie dann? Die Verstöße des Benutzers konnten nicht gefunden werden? Grammatisch gesehen ist das richtig, aber in der REST-Welt ist es einfach nicht richtig, wenn es bei Erfolg oder Misserfolg um die Anfrage geht. Die "Verstoß" -Daten für diesen Benutzer konnten erfolgreich gefunden werden, es gibt keine Verstöße - eine reelle Zahl, die einen gültigen Zustand darstellt.

[Freche Notiz ..]

In Ihrem Titel stimmen Sie unbewusst zu, dass 200 die richtige Antwort ist:

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

Bei der Auswahl des zu verwendenden Statuscodes sind folgende Punkte zu beachten, unabhängig von Subjektivität und schwierigen Entscheidungen:

1. Konsistenz . Wenn Sie 404 für "keine Daten" verwenden, verwenden Sie es jedes Mal, wenn eine Antwort keine Daten zurückgibt.
2. Verwenden Sie denselben Status nicht für mehr als eine Bedeutung . Wenn Sie 404 zurückgeben, wenn eine Ressource nicht gefunden wurde (z. B. API-Endpunkt existiert nicht usw.), verwenden Sie sie nicht auch für keine zurückgegebenen Daten. Dies macht den Umgang mit Reaktionen nur zu einem Schmerz.
3. Betrachten Sie den Kontext sorgfältig . Was ist die "Anfrage"? Was sagen Sie, was Sie erreichen wollen?

Codieren Sie den Antwortinhalt mit einer gemeinsamen Aufzählung, die es dem Client ermöglicht, ihn einzuschalten und die Logik entsprechend zu teilen. Ich bin nicht sicher, wie Ihr Client den Unterschied zwischen einer "Daten nicht gefunden" 404 und einer "Webressource nicht gefunden" 404 unterscheiden würde. Sie möchten nicht, dass jemand zu Benutzer Z / 9 navigiert und der Client sich wundert, als ob die Anforderung gültig wäre, aber keine Daten zurückgegeben wurden.

Warum nicht 410 verwenden? Es wird vorgeschlagen, dass die angeforderte Ressource nicht mehr vorhanden ist und der Client in Ihrem Fall voraussichtlich nie eine Anforderung für diese Ressource stellen wird users/9.

Weitere Informationen zu 410 finden Sie hier: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Es ist traurig, dass etwas so Einfaches und Definiertes in diesem Thread "meinungsbasiert" wurde.

Ein HTTP-Server kennt nur "Entitäten", die eine Abstraktion für jeden Inhalt darstellen, sei es eine statische Webseite, eine Liste von Suchergebnissen, eine Liste anderer Entitäten, eine JSON-Beschreibung von etwas, eine Mediendatei usw. usw.

Es wird erwartet, dass jede solche Entität durch eine eindeutige URL identifizierbar ist, z

• / user / 9 - eine einzelne Entität: eine USER ID = 9
• / users - eine einzelne Entität: eine LISTE aller Benutzer
• /media/x.mp3 - eine einzelne Entität: eine Mediendatei mit dem Namen x.mp3
• / search - eine einzelne Entität: ein dynamischer INHALT, der auf Abfrageparametern basiert

Wenn ein Server eine Ressource anhand der angegebenen URL findet, spielt es keine Rolle, wie ihr Inhalt lautet - 2G Daten, null, {}, [] - solange er vorhanden ist, sind es 200. Wenn dies jedoch der Fall ist Dem Server nicht bekannt, wird erwartet, dass 404 "Not Found" zurückgegeben wird.

Eine Verwirrung scheint von Entwicklern zu kommen, die denken, wenn die Anwendung einen Handler für eine bestimmte Pfadform hat, sollte dies kein Fehler sein. In den Augen des HTTP-Protokolls spielt es keine Rolle, was in den Interna des Servers passiert ist (dh ob der Standardrouter geantwortet hat oder ein Handler für eine bestimmte Pfadform), solange auf dem Server keine übereinstimmende Entität zum Server vorhanden ist Die angeforderte URL (die angeforderte MP3-Datei, Webseite, Benutzerobjekt usw.), die gültige Inhalte (leer oder anderweitig) zurückgeben würde, muss 404 (oder 410 usw.) sein.

Ein weiterer Punkt der Verwirrung scheint "keine Daten" und "keine Entität" zu sein. Ersteres betrifft den Inhalt einer Entität und letzteres ihre Existenz.

Beispiel 1:

• Keine Daten: / users gibt 200 OK zurück, body: [], da noch niemand registriert ist
• Keine Entität: / users gibt 404 zurück, da kein Pfad / users vorhanden ist

Beispiel 2:

• Keine Daten: / user / 9 gibt return 200 OK zurück, body: {}, da user ID = 9 seine persönlichen Daten nie eingegeben hat
• Keine Entität: / user / 9 gibt 404 zurück, da keine Benutzer-ID = 9 vorhanden ist

Beispiel 3:

• Keine Daten: / search? Name = Joe gibt 200 OK [] zurück, da sich keine Joes in der Datenbank befinden
• Keine Entität: / search? Name = Joe gibt 404 zurück, da kein Pfad / keine Suche vorhanden ist

404 wäre für jeden Kunden sehr verwirrend, wenn Sie zurückkehren, nur weil keine Daten als Antwort vorliegen.

Für mich reicht der Antwortcode 200 mit einem leeren Körper aus, um zu verstehen, dass alles perfekt ist, aber es gibt keine Daten, die den Anforderungen entsprechen.

Laut Microsoft: Rückgabetypen für Controller-Aktionen in der ASP.NET Core-Web-API scrollen Sie fast nach unten. Sie finden den folgenden Klappentext zu 404, der sich auf ein Objekt bezieht, das nicht in der Datenbank gefunden wurde. Hier schlagen sie vor, dass ein 404 für leere Daten geeignet ist.

Wie von vielen angegeben, ist 404 irreführend und erlaubt dem Client nicht zu unterscheiden, ob die Anforderungs-Uri nicht existiert oder ob die angeforderte Uri die angeforderte Ressource nicht abrufen kann.

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

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

Ich habe gesehen, dass dieses Thema an mehreren Stellen immer wieder diskutiert wurde. Für mich ist es schmerzlich offensichtlich, dass ein dedizierter Erfolgsstatus erforderlich ist, um die Verwirrung um das Thema zu beseitigen. So etwas wie " 209 - Keine Ressource zum Anzeigen".

Es handelt sich um einen 2xx-Status, da das Nichtfinden einer ID nicht als Clientfehler angesehen werden sollte (wenn die Clients alles wüssten, was sich in der Datenbank des Servers befindet, müssten sie dem Server keine Fragen stellen, oder?). Dieser dedizierte Status behandelt alle Probleme, die mit der Verwendung anderer Status diskutiert werden.

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