Welchen Http-Code soll ich für "Thing not found" zurückgeben?

404 Not Found ist die richtige Antwort, wenn es ein Service ist, wird es nicht wirklich von Menschen benutzt, sondern von Maschinen, und deshalb sollten Tippfehler nicht Ihre erste Sorge sein.

Außerdem gibt es sehr wenig, was Sie tun können, um dem menschlichen Verhalten überhaupt zu begegnen (wenn Sie eine Sache denken, wenn es wirklich eine andere ist). Wenn Sie einen kleinen Fehler msg als Teil des Fehlercodes zurückgeben, sollte alles funktionieren. Sie könnten ihnen sogar eine mögliche Lösung vorschlagen.

Eine 500 zurückzugeben, wenn die Anwendung genau das tut, was sie entwickelt hat, erscheint auch ein bisschen seltsam. 404 beschreibt genau die Situation: Ressource nicht gefunden.

Fehler 404 ist in diesem Fall tatsächlich eine akzeptablere Antwort, da die Ressource wirklich nicht gefunden wird. Sie könnten immer ein benutzerdefiniertes Fehlerdokument haben, das erklärt, dass die Benutzer-ID nicht gefunden wird.

Ein 400-Fehler bedeutet, dass der Client eine fehlerhafte Syntax gesendet hat, was in Ihrem Beispiel nicht der Fall ist. Daher sollten Sie diesen Fehlercode nicht verwenden. Es kann scheinen, dass "Ungültige Anfrage" korrekt ist, aber was dies tatsächlich bedeutet, ist ein Fehler in der Anfrage-Header-Syntax.

Dies ist auch kein 500 Fehler, weil kein Fehler aufgetreten ist. Es gibt kein Problem damit, dass der Webserver die Anfrage erfüllt. Tatsache ist, dass die Anfrage eine Ressource sucht, die nicht vorhanden ist.

404 ist die einzige geeignete Antwort, es sei denn, Sie möchten es als eine vollständig gültige Anfrage betrachten, geben Sie den Status 200 zurück und eine Seite, die erklärt, dass der angeforderte Benutzer nicht existiert.

Von meinem ursprünglichen Kommentar zu der Frage:

  

Ich glaube nicht, dass auch ein 200-stufiger Fehler angemessen wäre, bedenke die Erklärungen bei W3 w3. org / Protokolle / rfc2616 / rfc2616-sec10.html

IMHO, die HTTP-Antwort ist nicht der richtige Ort, um dies zu behandeln, da der Fehler nicht auf der HTTP-Ebene ist. Es ist auf Anwendungsebene. Eine mögliche Lösung besteht darin, das Null-Objekt-Muster zu verwenden, um eine Null "Benutzer" zurückzugeben, die der Patron-Schnittstelle entspricht, aber angibt dass keine solche Person existiert.

UPDATE: Ich bin davon überzeugt, dass diese Antwort falsch ist. Ich möchte es jedoch weglassen, da es sich um eine potenziell gültige Antwort handelt (abhängig von Details, die in der Frage nicht aufgeführt sind), und ich denke, dass die Kommentare lehrreich sind.

Wenn Ihr Dienst normalerweise einen Fehler entdeckt, den er nicht verarbeiten kann, aber die Anfrage ist gut formuliert, dann würde ich denken, dass Sie einen 500-Statuscode zurückgeben möchten.

Auch ein weiterer Grund, warum ich sage 500 wäre angemessen, ist, dass aus meiner Erfahrung in .NET Web Services, immer wenn ich eine Ausnahme über die Leitung (wie eine RecordNotFound Ausnahme) werfen, der Webserver und Client immer interpretiert haben Antwort auf einen 500 Statuscode.

Wie auch immer, es wäre eine gute Idee, diese Liste von http-Statuscodes zu überprüfen und Schön die, die Ihren Bedürfnissen am besten entspricht.

Es hängt davon ab, welche Art von Webservice Sie erstellen.

SOAP- und XML-Webdienste geben normalerweise 200 OK zurück, wenn ein angefordertes Objekt (Benutzer) nicht gefunden werden kann, und geben den Fehlertyp / die Nachricht / Beschreibung in das Antwortdokument ein. Sie trennen eine Transportebene (HTTP) von den ausgetauschten Nachrichten (XML). Ein 404-Fehler (der sich auf der Transportebene befindet) wird nur zurückgegeben, wenn Sie einen nicht vorhandenen API-Endpunkt (falsche URL) anfordern.

Mit einem REST-Webservice verwenden Sie jedoch HTTP-Methoden und Status direkt für den Nachrichtenaustausch. REST verwendet verschiedene HTTP-Methoden (GET / POST / PUT / DELETE), um anzugeben, welche Aktion gewünscht wird und der Server den Status als HTTP-Status zurückgibt. Im Falle eines REST-Webservice wäre 404 der richtige HTTP-Status, wenn ein Benutzer nicht gefunden werden konnte.

500 ist auf jeden Fall unpassend, da 5xx bedeutet, dass auf der Serverseite etwas nicht stimmt (was nicht der Fall ist), während 4xx Fehler bedeuten, dass auf der Client-Seite etwas nicht stimmt.

Es kann 4 Jahre alt sein, aber es ist immer noch ziemlich relevant. Für APIs, die sowohl von borwsers als auch von nativen Apps verwendet werden sollen, ist es viel einfacher, die HTTP-Codes für die Statusanzeige zu verwenden. Und wenn nötig, verwenden Sie ein paar zusätzliche Codes aus den nicht zugewiesenen für Bedingungen, die nicht gut zu bestehenden HTTP-Codes passen.

Wenn Sie die Antworten des Web-Service über HTTP-Antwortcodes steuern möchten, können Sie in der Tat eine 404 verwenden, um diese Bedingung anzuzeigen.

Ich denke jedoch, dass es natürlicher ist, die Antwort des Web-Service vollständig im Text der HTTP-Antwort zu definieren und 200 für eine erfolgreiche Kommunikation zurückzugeben ("Ich habe Ihre Anfrage verstanden und Ihnen eine angemessene Antwort geschickt"). . In diesem Fall würden Sie 200 wie üblich mit der Nutzlast Ihrer Anfrage (XML oder JSON oder was auch immer) zurückgeben, um anzuzeigen, dass keine übereinstimmende Entität gefunden wurde

Ich würde nicht-200 Fehlercodes berücksichtigen, die Ausnahmen in herkömmlichen Programmiersprachen ähneln, und der HTTP-Antwortkörper ähnelt eher dem Rückkehrcode. Stellen Sie sich vor, Sie würden dies konventionell implementieren - würden Sie eine Ausnahme auslösen, wenn keine Entität gefunden wurde, oder null zurückgeben? Angesichts der fragilen Natur von Netzwerkverbindungen möchte ich natürlich alle HTTP-Level-Fehlercodes für Probleme bei der Kommunikation reservieren, und ich würde lieber immer 200 OK vom Dienst selbst zurückgeben, zusammen mit einer Payload, die das Ergebnis angibt oder jeder Service-Level-Fehler.