it-swarm.com.de

Was ist das Richtige? REST Antwortcode für eine gültige Anfrage, aber leere Daten?

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

  • 200 OK
  • 202 akzeptiert
  • 204 Kein Inhalt
  • 400 schlechte Anfrage
  • 404 Nicht gefunden
223
IMB

TL; DR: Benutze 404

Siehe Dieser Blog . Das 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 es laut HTTP-Spezifikation von Browsern als Antwortcode verstanden werden muss, dass die Ansicht nicht geändert wird).
  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 DELETE oder POST, die kein Feedback erfordern).

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

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

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

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

209
Crisfole

Ich widersetze mich 404 mit 204 oder 200 mit leeren Daten.

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

Noch wichtiger ist, dass 404 aus verschiedenen technischen Gründen vorkommen kann. Z.B. Die Anwendung wird auf dem Server vorübergehend deaktiviert oder deinstalliert. Es gibt Probleme mit der Proxy-Verbindung und so weiter. Daher kann der Client nicht zwischen einem 404, der "leere Ergebnismenge" bedeutet, und einem 404, der "der Dienst kann nicht gefunden werden können, zu einem späteren Zeitpunkt versuchen" unterscheiden. 

Dies kann fatal sein: Stellen Sie sich einen Buchhaltungsservice in Ihrem Unternehmen vor, in dem alle Mitarbeiter aufgeführt sind, die aufgrund eines Jahresbonus gezahlt werden. Leider wird beim einmaligen Aufruf ein 404 zurückgegeben. Bedeutet das, dass niemand für einen Bonus fällig ist oder dass die Anwendung derzeit für eine neue Bereitstellung ausfällt? 

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

Außerdem reagieren viele Client-Frameworks auf 404, indem sie eine Ausnahme ohne weitere Fragen auslösen. Dies zwingt den Client-Entwickler, diese Ausnahmebedingung abzufangen, auszuwerten und daraufhin zu entscheiden, ob sie als Fehler protokolliert wird, der z. eine Überwachungskomponente oder ob sie ignoriert werden soll. Das erscheint mir auch nicht hübsch.

Der einzige Vorteil von 404 gegenüber 204 ist, dass eine Antworteinheit zurückgegeben werden kann, die Informationen darüber enthält, warum die angeforderte Ressource nicht gefunden wurde. Wenn dies wirklich relevant ist, kann auch die Verwendung einer 200-OK-Antwort in Betracht gezogen und das System so entworfen werden, dass Fehlerantworten in den Nutzdaten möglich sind. Alternativ könnte man die Nutzdaten der 404-Antwort verwenden, um strukturierte Informationen an den Anrufer zurückzugeben. Wenn er z. Eine HTML-Seite anstelle von XML oder JSON, die er parsen kann, ist ein guter Indikator dafür, dass etwas Technisches schiefgegangen ist, statt einer Antwort "Kein Ergebnis", die möglicherweise aus Sicht des Anrufers gültig ist. 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, das ist das Ergebnis, man muss 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 trotz einer korrekten technischen Ausführung kann der Client 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" ist wie das 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 mit einem gültigen Ergebnis verwechselt würde.

250
Jens Wurm

Zuerst dachte ich, eine 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

Hintergrund:

  1. die Suche gibt ein Array zurück, es hat einfach keine Übereinstimmungen gegeben, aberit 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/:name mit users/kyle übereinstimmt, ist der Benutzer Kyle nicht als Ressource verfügbar, daher gilt weiterhin ein 404. Es handelt sich nicht um eine Suchanfrage, es handelt sich um eine direkte Referenz durch eine dynamische URL , also 404.

Wie auch immer, meine zwei Cents :)

19
Justus Romijn

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

Also hätte ich lieber/things ein 200 OK mit {"Items": []} als ein 204 mit nichts zurückgeben, weil auf diese Weise eine Collection mit 0 Items genauso behandelt werden kann wie eine Collection mit einem oder mehr Artikel drin.

Ich würde nur die Option "Kein Inhalt für PUTs und DELETEs" belassen, wobei es tatsächlich der Fall sein könnte, dass es wirklich keine nützliche Repräsentation gibt.

Falls/thing/9 wirklich nicht existiert, ist ein 404 angebracht.

19
j0057

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.

Wenn ein Objekt vorhanden ist, aber keine Daten vorhanden sind, wäre kein Inhalt geeignet. Ich denke, in Ihrem Fall existiert das Objekt nicht.

18
Max

Nach w3 post,

200 OK 

Die Anfrage ist erfolgreich verlaufen. 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, aber die Verarbeitung wurde noch nicht abgeschlossen.

204 Kein Inhalt

Der Server hat die Anforderung erfüllt, muss jedoch keinen Entity-Body zurückgeben und möchte möglicherweise aktualisierte Metainformationen zurückgeben.

400 Fehlerhafte Anforderung 

Die Anfrage 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

10
Dev4World

Zusammenfassend oder vereinfachend: 

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

4xx: Erwartete Daten: Nicht wohlgeformte URI: Kriterien sind Teil der URI: Wenn das Kriterium obligatorisch ist und nur in @PathVariable angegeben werden kann, sollte es zu 4xx führen. Beispiel: Nach eindeutiger ID suchen.

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

9
Ashish Singh

Es werden zwei Fragen gestellt. Einer im Titel und einer im Beispiel. Ich denke, dass dies teilweise zu einem Streit geführt hat, welche Reaktion angemessen ist.

Der Fragentitel fragt nach leeren Daten. Leere Daten sind immer noch Daten, sind jedoch nicht identisch mit keinen Daten. Dies schlägt also vor, eine Ergebnismenge anzufordern, d. H. Eine Liste, vielleicht von /users. Wenn eine Liste leer ist, ist sie immer noch eine Liste, daher ist eine 204 (Kein Inhalt) am besten geeignet. Sie haben gerade nach einer Liste von Benutzern gefragt und erhalten eine. Es ist nur zufällig kein Inhalt. 

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 eine 404-Adresse geeignet. 

Ich denke, der Weg, das herauszufinden, ist, wenn Sie die Antwort auf die Weise verwenden können, die Sie 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 prü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 sie 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.

7
Bluebox

Was die vorhandenen Antworten nicht näher erläutern, ist, dass es einen Unterschied macht, ob Sie Pfadparameter oder Abfrageparameter verwenden.

  • Bei Pfadparametern ist der Parameter Teil des Ressourcenpfads. Im Fall von /users/9 sollte die Antwort 404 sein, da diese Ressource nicht gefunden wurde. /users/9 ist die Ressource und das Ergebnis ist unary oder ein Fehler ist nicht vorhanden. Dies ist nicht eine Monade.
  • Bei Abfrageparametern ist der Parameter nicht Teil des Ressourcenpfads. Im Fall von /users?id=9 sollte die Antwort 204 sein, da die Ressource /users gefunden wurde, jedoch keine Daten zurückgegeben werden konnten. Die Ressource /users ist vorhanden und das Ergebnis ist n-ary. Sie ist auch vorhanden, wenn sie leer ist. Wenn id eindeutig ist, ist dies eine - Monade.

Ob Pfadparameter oder Abfrageparameter verwendet werden, hängt vom Anwendungsfall ab. Ich bevorzuge Pfadparameter für obligatorische, normative oder das Identifizieren von Argumenten und Abfrageparameter für optionale, nicht normative oder Attributattribute (z. B. Paging, Kollatierungsgebietsschema und Zeug). In einer REST - API würde ich /users/9 nicht /users?id=9 verwenden, insbesondere wegen der möglichen Verschachtelung, um "untergeordnete Datensätze" wie /users/9/ssh-keys/0 zu erhalten, um den ersten öffentlichen SSH-Schlüssel zu erhalten, oder /users/9/address/2, um die dritte Postadresse zu erhalten.

Ich ziehe es vor, 404 zu verwenden.

  • Aufrufe für unäre (1 Ergebnis) und n-ary (n Ergebnisse) Methoden sollten sich nicht aus gutem Grund unterscheiden. Ich möchte möglichst dieselben Antwortcodes haben. Die Anzahl der erwarteten Ergebnisse ist natürlich ein Unterschied, zum Beispiel erwarten Sie, 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 für den Fall, dass keine Ergebnisse vorliegen, würde ich kein Set zurückgeben (kein Dokument). Ich würde ein leeres Set 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 den Draht zu legen, außer in den Körper.
  • 204 ist wie eine void-Methode. Ich würde es nicht für GET verwenden, nur für POST, PUT und DELETE. Ich mache eine Ausnahme für GET, wobei die Bezeichner Abfrageparameter und nicht Pfadparameter sind.
  • Wenn der Datensatz nicht gefunden wird, ist dies wie NoSuchElementException, ArrayIndexOutOfBoundsException oder ähnliches. Er wird dadurch verursacht, dass der Client eine nicht vorhandene ID verwendet. Es handelt sich also um einen Clientfehler.
  • Aus der Code-Perspektive bedeutet das Ermitteln von 204 einen zusätzlichen Zweig im Code, der vermieden werden könnte. Es verkompliziert Client-Code und in einigen Fällen auch Server-Code (abhängig davon, ob Sie EntitätsModell-Monaden oder einfache Entitäten/Modelle verwenden; und ich dringend empfehle, sich von Entitäts-/Modell-Monaden fernzuhalten, kann dies zu führen böse Bugs, bei denen Sie aufgrund der Monade denken, dass eine Operation erfolgreich ist, und geben 200 oder 204 zurück, wenn Sie tatsächlich etwas anderes zurückgegeben haben sollten).
  • Client-Code ist einfacher zu schreiben und zu verstehen, wenn 2xx bedeutet, dass der Server die vom Client angeforderten Anforderungen ausführt, und 4xx bedeutet, dass der Server nicht die vom Client angeforderten Anweisungen ausführt und der Client die Schuld hat. Dem Client nicht den Datensatz zu geben, den der Client von id angefordert hat, ist der Fehler des Clients, da der Client eine nicht vorhandene ID angefordert hat.

Zu guter Letzt: Konsistenz

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

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

Außerdem ist dies kein normativer, sondern ein kultureller Grund: Wenn 204 für GET /users/9 verwendet wird, geschieht als nächstes, dass jemand denkt, dass 204 für n-ary-Methoden gut ist. Und dies macht den Client-Code komplizierter, da der Client nicht nur nach 2xx suchen und dann den Body decodieren muss, sondern gezielt nach 204 suchen und in diesem Fall die Decodierung des Body überspringen muss. Knospe, was macht der Kunde stattdessen? Ein leeres Array erstellen? Warum haben wir das nicht auf dem Draht? Wenn der Client das leere Array erstellt, ist 204 eine Form der blöden Komprimierung. Wenn der Client stattdessen null verwendet, wird eine völlig andere Dose Würmer geöffnet.

4
Christian Hujer

204 ist besser geeignet. Insbesondere wenn Sie über ein Alarmsystem verfügen, um sicherzustellen, dass Ihre Website sicher ist, würde 404 in diesem Fall Verwirrung stiften, weil Sie nicht wissen, dass einige 404-Alarme Backend-Fehler oder normale Anforderungen sind, aber die Antwort leer ist.

3
刘武豪

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

6.5.4. 404 Not Found Der Statuscode 404 (Not Found) gibt an, dass der Origin-Server keine aktuelle Darstellung für die Zielressource gefunden hat oder nicht bereit ist, anzugeben, dass eine vorhanden ist. Ein Statuscode 404 gibt nicht an, ob Dieser Mangel an Repräsentation ist vorübergehend oder dauerhaft, der Statuscode 410 (Gone) wird dem Statuscode 404 vorgezogen, wenn der Origin-Server vermutlich durch konfigurierbare Mittel weiß, dass der Zustand wahrscheinlich dauerhaft ist sofern in der Methodendefinition oder den 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. Gemäß demselben RFC (7231) lautet die Definition der Ressource:

Ressourcen: Das Ziel einer HTTP-Anforderung wird als "Ressource" bezeichnet. HTTP beschränkt nicht die Art einer Ressource, sondern definiert lediglich eine Schnittstelle, die zur Interaktion mit Ressourcen verwendet werden kann. Jede Ressource wird durch eine einheitliche Ressourcen-ID identifiziert (URI), wie in Abschnitt 2.7 von [RFC7230] beschrieben. Wenn ein Client eine HTTP/1.1-Anforderungsnachricht erstellt, sendet er den Ziel-URI in einer der in (Abschnitt 5.3 von [RFC7230]) definierten Formen Wenn eine Anforderung empfangen wird, stellt der Server eine effektive Anforderungs-URI für die Zielressource wieder her (Abschnitt 5.5 von [RFC7230]). Ein Entwurfsziel von HTTP besteht darin, die Ressourcenidentifikation von der Anforderungssemantik zu trennen Methode (Abschnitt 4) und einige anforderungsmodifizierende Header-Felder (Abschnitt 5) Wenn ein Konflikt zwischen der Methodensemantik und einer von der URI selbst implizierten Semantik besteht, wie in Abschnitt 4.2.1 beschrieben, hat die Methodensemantik Vorrang.

Meines Wissens 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)

2
Filipe Moisés

Ich würde sagen, keiner ist wirklich angemessen .. Wie gesagt - z. Ich denke auch, dass ein Teil der Probleme auf die Verwendung eines HTTP-Antwortcodes zurückzuführen ist, um einen Status zu übertragen, der sich auf einen RESTful-Dienst bezieht. Alles, was der Dienst REST über seine eigene Verarbeitung zu sagen hat, sollte mithilfe von REST - spezifischen Codes transportiert werden.

1

Ich behaupte, 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, der Server hat dies ausdrücklich gesagt Dienst, 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, ist 404 korrekt. Dasselbe gilt, wenn ein Dienst zur Bereitstellung genau dieser Datei aufgefordert wird und dieser Dienst ihm mitteilt, dass nichts von diesem Namen existiert.
  • In Fall B arbeitet der Server nicht mit "echten" Dateien, aber die Anforderung wird tatsächlich von einem anderen Dienst bearbeitet, z. eine Art Templationssystem. Hier kann der Server keinen Anspruch auf das Vorhandensein der Ressource erheben, da er nichts davon weiß (es sei denn, der Service teilt es 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 bearbeiten soll, nicht ausgeführt wird oder antwortet;
  • 200 Andernfalls kann der HTTP-Server die Anforderung tatsächlich erfüllen - unabhängig davon, was der Dienst später sagt.
  • 400 oder 404, um anzuzeigen, dass es keinen solchen Dienst gibt (im Gegensatz zu "existiert, aber offline") und nichts anderes gefunden wurde.

2

Um auf die Frage zurückzukommen: Ich denke, der sauberste Ansatz wäre, keinen HTTP-Antwortcode zu verwenden, der nicht anders als zuvor erwähnt wurde. Wenn der Dienst vorhanden ist und antwortet, sollte der HTTP-Code 200. Die Antwort sollte den Status enthalten, den der Dienst in einem separaten Header zurückgegeben hat - hier kann der Dienst sagen

  • REST:EMPTY z.B. wenn gefragt wurde, nach etw. zu suchen und diese Forschung kehrte leer zurück;
  • REST:NOT FOUND wenn es speziell nach etw. gefragt wurde. "ID-like" - 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 er gesendet hat, vom Dienst nicht erkannt wird.

(Beachten Sie, dass ich vorab "REST:" vorangestellt habe, um die Tatsache hervorzuheben, dass diese zwar dieselben Werte oder denselben Wortlaut wie HTTP-Antwortcodes haben können, sie jedoch etw. völlig verschieden sind.

3

Gehen wir zurück zur obigen URL und prüfen Sie Fall B, in dem service dem HTTP-Server anzeigt, dass er diese Anforderung nicht selbst bearbeitet, sondern an SERVICE weiterleitet. HTTP gibt nur das aus, was von SERVICE zurückgegeben wird. Es kennt nichts über den return/test-Abschnitt, da dieser von SERVICE abgewickelt wird. Wenn dieser Dienst ausgeführt wird, sollte HTTP 200 zurückgeben, da tatsächlich etwas gefunden hat, um die Anforderung zu bearbeiten.

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

  • wenn return/test nach einer bestimmten Ressource fragt, geben Sie die Ressource mit dem Status REST:FOUND zurück. Wenn diese Ressource nicht vorhanden ist, geben Sie REST:NOT FOUND zurück. dies könnte erweitert werden, um REST:GONE zurückzugeben, wenn wir wissen, dass es einmal existiert hat und nicht zurückkehren wird, und REST:MOVED, wenn wir wissen, dass es hollywood gegangen ist
  • wenn return/test als such- oder filterähnliche Operation gilt: Wenn die Ergebnismenge leer ist, geben Sie eine leere Menge des angeforderten Typs und den Status REST:EMPTY zurück. eine Reihe von Ergebnissen im angeforderten Typ und einen Status von REST:SUCCESS
  • wenn return/test keine durch SERVICE erkannte Operation ist: return REST:ERROR wenn es vollständig falsch ist (z. B. ein Tippfehler wie retrun/test) oder REST:NOT IMPLEMENTED, falls dies für später geplant ist.

4

Diese Unterscheidung ist viel sauberer als das Vermischen der zwei verschiedenen Dinge. Außerdem wird das Debugging einfacher und die Verarbeitung wird, wenn überhaupt, nur geringfügig komplexer.

  • Wenn ein HTTP 404 zurückgegeben wird, sagt der Server: "Ich habe keine Ahnung, wovon Sie sprechen". Auch wenn der REST -Abschnitt meiner Anfrage vielleicht in Ordnung ist, suche ich an allen falschen Stellen nach Par'Mach.
  • Andererseits 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: LEER, ich weiß, 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 bedient werden, oder um etw zu kennzeichnen. das liegt nicht im Bereich des HTTP-Servers selbst .. Aufgrund dieser Diskrepanz kann die Frage nicht beantwortet werden und alle Meinungen werden viel diskutiert.Der Status einer Anforderung, die von einem Dienst verarbeitet wird, und nicht der HTTP-Server, der sich WIRKLICH NICHT (RFC 6919) befinden sollte, wird durch einen HTTP-Antwortcode angegeben. Der HTTP-Code SHOULD (RFC 2119) enthält nur Informationen, die der HTTP-Server aus seinem eigenen Bereich geben kann, nämlich, ob der Dienst die Anfrage verarbeiten konnte oder nicht.

Stattdessen sollte ein anderer Weg 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 eine bestimmte Kopfzeile zu tun. Idealerweise folgen sowohl der Name des Headers als auch dessen Inhalt einem Standard, der es Verbrauchern erleichtert, mit diesen Antworten zu arbeiten.

Instead, a different way SHOULD be used to tell a consumer about the state of the request to the service that is actually processing the request. My proposal is to do so via a specific header. Ideally, both the name of the header and its contents follow a standard that makes it easy for consumers to work with theses responses.

2
dariok

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

Basierend auf RFC 7231 lautet der korrekte Statuscode 204

In den Antworten oben bemerkte ich ein kleines Missverständnis:

1.- Die Ressource ist: /users

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

so:

Basierend auf dem RFC: 404 ist falsch, da der /users der Ressourcen gefunden wird, aber die mit dem Parameter 8 ausgeführte Logik keine content gefunden hat, die als Antwort zurückgegeben werden kann. Die richtige Antwort lautet daher: 204

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

204 ist a: Ich habe die Ressource gefunden, die Logik wurde ausgeführt, aber ich habe unter Verwendung Ihrer im Routenparameter angegebenen Kriterien keine Daten gefunden, sodass ich nichts an Sie 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, irgendetwas 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 diese in einer Ansicht freigeben möchten, aktualisieren Sie die Ansicht um es anzuzeigen.

Ich hoffe es hilft.

2
rodfraga

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

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

1
Jay

Kodieren Sie den Antwortinhalt mit einer allgemeinen Enumeration, die es dem Client ermöglicht, ihn zu aktivieren und die Logik entsprechend zu verzweigen. Ich bin nicht sicher, wie Ihr Client den Unterschied zwischen einem "Daten nicht gefunden" 404 und einem "Webressourcen nicht gefunden" 404 unterscheiden würde. Sie möchten nicht, dass jemand zu userZ/ 9 wechselt, und der Client fragt sich, als sei die Anfrage gültig, aber es wurden keine Daten zurückgegeben. 

0
ComeIn

Warum nicht 410 verwenden? Es schlägt vor, dass die angeforderte Ressource nicht mehr vorhanden ist, und es wird erwartet, dass der Client niemals eine Anforderung für diese Ressource vornimmt, in Ihrem Fall users/9.

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

0
Akshat