Welche Http Code sollte ich zurückkehren für „Thing nicht gefunden“?

https://stackoverflow.com/questions/1027300

06-07-2019
|

Frage

Ich bin der Aufbau einen Web-Dienstes, der verwendet wird, in diesem speziellen Fall für Informationen über einen Mäzen zu fragen.

Lassen Sie uns sagen, aus Gründen der Argumentation, dass die Lookup-Web-Hit ist:

GET /patrons/619 HTTP/1.1

Wenn der Patron gefunden wird, i Return-Code 200:

HTTP/1.1 200 OK

Wenn Sie nicht angeben, oder eine Kontonummer geben, die keine Zahl ist, kehre ich 400. Zum Beispiel der folgenden schlechten Anfragen:

GET /patrons HTTP/1.1
GET /patrons/ HTTP/1.1
GET /patrons/G619 HTTP/1.1
GET /patrons/kirsten%20guyer HTTP/1.1

alle zurück Fehler 400 (Bad Request), z.

HTTP/1.1 400 Invalid patron number

i für einen Statuscode haben will Mäzene nicht gefunden , kehrte als HTTP-Statuscode. Zum Beispiel:

GET /patrons/1322 HTTP/1.1

HTTP/1.1 404 Not Found

Ich habe darüber nachgedacht, mit 404 (nicht gefunden) , die ist eine gültige Antwort (die angeforderte Ressource war, wirklich und wirklich, nicht gefunden.) Aber ich habe Angst Menschen Debuggen es könnte denken, dass es bedeutet, dass sie geschrieben /patrons/ falsch.

Kann jemand denken Sie an einen anderen HTTP-Statuscode i verwenden könnte?

Update: Ich bin Anglotzen

204 No Content 
The server successfully processed the request, but is not returning any content.

Was sagen Sie?

Vergessen Sie nicht, dass nicht alle HTTP-Server HTML-Inhalte dienen werden. Wenn ein IIS-Web-Server wird für eine Ressource gefragt genannt:

GET /MyStartPage.html HTTP/1.1

Dann wird der HTTP-Server hat zu entscheiden, was mit zu reagieren. Auf den meisten Web-Server, eine Ressource mit dem Namen /MyStartPage.html entspricht eine Datei auf der Festplatte sitzen.

Während Stackoverflow tut:

GET /posts/1027301 HTTP/1.1

Welche, wenn die Ressource nicht vorhanden ist, die Web-Server sollte (zu Recht) zurückkehren 404.

Lösung

404 Not Found ist die richtige Sache zurückzukehren, wenn es einen Service, es ist nicht wirklich von den Menschen genutzt, sondern von Maschinen, und deshalb Fehler, sollten Ihre erste Sorge nicht sein.

Auch gibt es sehr wenig ist man menschliches Verhalten zu begegnen ohnehin in der Lage sein zu tun werden (denken eine Sache, wenn es wirklich eine andere). Wenn Sie ein wenig Fehler msg als Teil des Fehlercodes zurückkehrt, sollte alles klappen. Man könnte sogar ihnen eine mögliche Lösung vorschlagen.

ein 500 zurückkehrend, wenn die Anwendung genau das tut, was es zu tun fertigt scheint auch ein wenig seltsam. 404 beschreibt genau die Situation. Ressource nicht gefunden

Andere Tipps

Ich glaube, Sie 404. Entwickler des API, was 404 Mittel werden verstehen, verwenden sollten, und werden daher dort, um eigene übliche Bugprozess folgen, das Problem zu lösen. Halten Sie sich an das Protokoll.

Error 404 ist tatsächlich eine akzeptable Antwort für diesen Fall, da die Ressource wirklich nicht gefunden wird. Sie können immer ein benutzerdefinierten Fehler Dokument, das erklärt, dass sie die Benutzungsnummer ist, die nicht gefunden wird.

Ein 400-Fehler bedeutet, dass der Kunde fehlerhafte Syntax gesendet, was nicht der Fall in Ihrem Beispiel. Daher sollten Sie nicht diesen Fehler verwenden. Es scheint, dass „Bad Request“ genau ist, aber was das eigentlich bedeutet, ist es ein Fehler in der Request-Header-Syntax.

Das ist auch keine 500 Fehler, da kein Fehler aufgetreten ist. Es gibt kein Problem mit dem Web-Server die Anforderung zu erfüllen, ist die Tatsache, dass die Anforderung eine Ressource sucht, die nicht vorhanden ist.

404 ist die einzige angemessene Antwort, wenn Sie es eine voll gültige Anforderung prüfen wollen, Zustand zurückzukehren 200 und eine Seite zu erklären, dass die angeforderte Patron existiert nicht.

Von meinem ursprünglichen Kommentar auf der Frage:

Ich glaube nicht, dass ein 200-Level-Fehler entweder angemessen wären, sollten Sie die Erklärungen auf W3 w3.org/Protocols/rfc2616/rfc2616-sec10.html

IMHO, die HTTP-Antwort ist nicht der richtige Ort, dies zu handhaben, da der Fehler nicht auf HTTP-Ebene ist. Es ist auf der Anwendungsebene. Eine mögliche Lösung ist die Object Pattern Null ein Null ‚Patron‘ zurückzukehren, die konform die Patron-Schnittstelle, sondern zeigt an, dass keine solche Person existiert.

UPDATE: Ich habe davon überzeugt, dass diese Antwort ist falsch. Allerdings mag ich es überlassen, da es eine potentiell gültige Antwort (abhängig von Details nicht in der Frage vorgelegt) ist, und ich denke, dass die Kommentare instruktiv sind.

Normalerweise, wenn Ihr Dienst einen Fehler feststellt, dass er nicht in der Lage zu handhaben, aber die Anforderung wird gut geformt, dann würde ich denken, dass Sie einen 500-Statuscode zurückgeben möchten.

Auch ein weiterer Grund, warum ich sage, 500 angebracht wäre, ist, dass aus meiner Erfahrung in .NET Web Services, wann immer ich eine Ausnahme über den Draht (wie eine RecordNotFound Ausnahme) werfen, haben die Web-Server und Client immer interpretted die Antwort ein 500-Statuscode sein.

So oder so, es wäre eine gute Idee, dieses Liste Meinung von hTTP-Statuscodes und fein die, die Ihren Bedürfnissen die besten Suiten.

Es hängt davon ab, welche Art von webservice Sie konstruieren.

SOAP und XML Web Service zurückkehrt typischerweise 200 OK, wenn ein angefordertes Objekt (Patron) nicht und kodieren den Fehlertyp / Meldung / Beschreibung in das Antwortdokument gefunden werden. Sie trennen eine Transportebene (HTTP) von den ausgetauschten Nachrichten (XML). Ein 404-Fehler (die auf der Transportebene ist) wird nur dann zurückgegeben, wenn Sie eine nicht vorhandene API-Endpunkt (falsche URL) anfordern.

Mit einem REST-Webservice jedoch verwenden Sie HTTP-Methoden und Zustände direkt für den Nachrichtenaustausch. REST verwendet verschiedene HTTP-Methoden (GET / POST / PUT / DELETE) festlegen, welche Aktion gesucht und der Server gibt den Status als HTTP-Status. So im Fall eines REST-Webservice, wäre 404 der richtige HTTP-Status, wenn ein Kunde kann nicht gefunden werden.

500 ist unangemessen auf jedem Fall denke ich, da 5xx bedeutet, dass etwas nicht in Ordnung auf dem server gewesen ist (was nicht der Fall ist), während 4xx Fehler bedeuten, dass es etwas falsch auf der Client-Seite.

Es kann 4 Jahre alt sein, aber es ist immer noch ziemlich relevant. Für APIs, die von beiden borwsers und native Anwendungen eingesetzt werden sollen, finde ich es viel einfacher ist, den HTTP-Codes für die Statusanzeige zu verwenden. Und wenn nötig ein paar zusätzlicher Codes aus den nicht zugeordneten diejenigen, für die Bedingungen, die keine gute Anpassung an bestehenden HTTP-Codes haben.

Fehler bei den Web-Service-Level sollten nicht nur eine einfache HTTP-Statuszeile zurück, sondern sollten stattdessen zurückgeben Inhalt in einem gültigen und dokumentierten Format, die vom Client analysiert werden kann Ihren Dienst zugreifen. Das zurückgegebene Dokument sollte einen Fehlercode enthält, den Teil eines dokumentierten Satz von Codes speziell für Ihren Web-Service, sowie eine kurze Beschreibung des Problems und gegebenenfalls eine ausführlichere Beschreibung des Problems ist.

Wenn Sie die Web-Service-Antworten über HTTP-Response-Codes steuern möchten, dann könnte man in der Tat eine 404 verwenden um diesen Zustand anzuzeigen.

Allerdings würde ich denke, es natürlich ist die Web-Service-Antwort vollständig im Körper der HTTP-Antwort definiert zu haben, und kehren nur 200 für eine erfolgreiche Kommunikation ( „Ich verstand Ihre Anfrage und haben Sie eine entsprechende Antwort gesendet“) . In diesem Fall wird dann würden Sie 200 als normal zurück mit der Nutzlast Ihrer Anfrage (XML oder JSON oder was auch immer), das anzeigt, dass keine passende Einheit gefunden wurde

würde ich nicht-200-Fehlercodes ähnlich wie Ausnahmen in herkömmlichen Programmiersprachen, und die HTTP-Antwort Körper mehr wie der Return-Code betrachten. Stellen Sie sich vor, wenn Sie diese in herkömmlicher Weise umsetzten - würden Sie eine Ausnahme auslösen, wenn keine Einheit gefunden wurde oder null zurückkehren? Persönlich die fragile Natur der Netzwerkverbindungen gegeben, würde ich möchte alle HTTP-Level-Fehlercodes für Probleme in der Kommunikation behalten, und ich würde viel lieber immer wieder zurückkehren 200 OK vom Dienst selbst, zusammen mit einer Nutzlast das Ergebnis Angabe oder jede Dienstleistung -Level-Fehler.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow