Sollte ich HTTP-Statuscodes verwenden, um Ereignisse auf Anwendungsebene zu beschreiben?

Einige Server, mit denen ich mich befasst habe, geben HTTP 200 für Anforderungen zurück, bei denen der Client einen Fehler in Betracht ziehen sollte, mit so etwas wie "Erfolg: Falsch" im Körper.

Dies scheint mir keine ordnungsgemäße Implementierung von HTTP-Codes zu sein, insbesondere bei fehlgeschlagener Authentifizierung. Ich habe HTTP-Fehlercodes kurz und bündig gelesen, da "4xx" angibt, dass die Anforderung erst nach einer Änderung erneut ausgeführt werden soll, während "5xx" angibt, dass die Anforderung möglicherweise gültig ist oder nicht und erneut versucht werden kann, aber erfolglos war. In diesem Fall 200: Anmeldung fehlgeschlagen, oder 200: Datei konnte nicht gefunden werden, oder 200: Parameter x fehlt, scheint definitiv falsch zu sein.

Andererseits konnte ich das Argument sehen, dass "4xx" nur ein strukturelles Problem mit der Anfrage anzeigen sollte. Das ist also richtig, um 200 zurückzugeben: Falscher Benutzer / falsches Kennwort anstatt 401 nicht autorisiert, da der Client die Anfrage stellen darf, sie aber falsch ist. Dieses Argument lässt sich so zusammenfassen, dass der Antwortcode 200 betragen sollte, wenn der Server die Anforderung verarbeiten und überhaupt eine Entscheidung treffen konnte, und der Client den Body auf weitere Informationen überprüfen muss.

Grundsätzlich scheint dies eine Frage der Präferenz zu sein. Aber das ist unbefriedigend. Wenn also jemand einen Grund hat, warum eines dieser Paradigmen korrekter ist, würde ich gerne wissen.

Interessante Frage.

Grundsätzlich können wir dies auf den richtigen Weg reduzieren, um Dinge analog zu OSI-Schichten zu klassifizieren. HTTP wird üblicherweise als Protokoll auf Anwendungsebene definiert, und HTTP ist in der Tat ein generisches Client / Server-Protokoll.

In der Praxis ist der Server jedoch fast immer ein Weiterleitungsgerät, und der Client ist ein Webbrowser, der für das Interpretieren und Rendern von Inhalten verantwortlich ist: Der Server leitet die Dinge nur an eine beliebige Anwendung weiter, und diese Anwendungen senden beliebige Skripts zurück, die der Browser sendet ist verantwortlich für die Ausführung. Die HTTP-Interaktion selbst - die Anfrage- / Antwortformulare, Statuscodes usw. - ist hauptsächlich eine Frage der Frage, wie beliebige Inhalte so effizient wie möglich angefordert, bereitgestellt und wiedergegeben werden können, ohne sich in die Quere zu kommen. Viele der Statuscodes und Header sind in der Tat für diese Zwecke konzipiert.

Das Problem beim Versuch, das HTTP-Protokoll für die Verarbeitung anwendungsspezifischer Flows zu huckepacken, besteht darin, dass Sie nur eine von zwei Optionen haben: 1) Sie müssen Ihre Anforderungs- / Antwortlogik zu einer Teilmenge der HTTP-Regeln machen. oder 2) Sie müssen bestimmte Regeln wiederverwenden, und dann wird die Trennung von Bedenken in der Regel unscharf. Das kann auf den ersten Blick schön und sauber aussehen, aber ich denke, es ist eine dieser Designentscheidungen, die Sie am Ende bereuen, wenn sich Ihr Projekt weiterentwickelt.

Daher würde ich sagen, dass es besser ist, explizit über die Trennung von Protokollen zu sprechen. Lassen Sie den HTTP-Server und den Webbrowser ihr eigenes Ding machen und lassen Sie die App ihr eigenes Ding machen. Die App muss in der Lage sein, Anforderungen zu stellen, und sie muss die Antworten bereitstellen. Die Logik zum Anfordern und Interpretieren der Antworten kann komplexer (oder weniger komplexer) sein als die HTTP-Perspektive.

Der andere erwähnenswerte Vorteil dieses Ansatzes besteht darin, dass Anwendungen im Allgemeinen nicht von einem zugrunde liegenden Transportprotokoll abhängig sein sollten (aus logischer Sicht). HTTP selbst hat sich in der Vergangenheit geändert, und jetzt haben wir HTTP 2, das SPDY folgt. Wenn Sie Ihre App als nicht mehr als ein HTTP-Funktions-Plug-in betrachten, können Sie dort hängen bleiben, wenn neue Infrastrukturen übernommen werden.

Diese Frage ist ein bisschen meinungsbasiert, aber so oder so.

So wie ich es sehe, können 200 "weiche Fehler" auslösen. Beim Erstellen von APIs versuche ich, zwischen diesen und "harten Fehlern" zu unterscheiden.

"Soft Errors" werden mit einem Statuscode von 200 bedient, enthalten jedoch eine Fehlerbeschreibung und den Erfolgsstatus von false. "Weiche Fehler" treten nur auf, wenn das Ergebnis "wie erwartet" ist, aber nicht im engeren Sinne ein Erfolg.

Es ist wichtig zu beachten, dass "weiche Fehler" eher ein Hinweis für den Implementierer sind. Aus diesem Grund ist es wichtig, weitere Informationen zu dem Fehler bereitzustellen, z. B. eine von Menschen lesbare Fehlermeldung und / oder eine Art Code, mit dem der Endbenutzer eine Rückmeldung erhalten kann. Diese Fehler liefern dem Implementierer (und dem Endbenutzer) weitere Informationen darüber, was auf der Serverseite passiert ist .

Angenommen, Sie haben eine API mit einer Suchfunktion, aber während einer Suche werden keine Ergebnisse ausgegeben. Dies ist nicht falsch, aber es ist auch kein "Erfolg", nicht im engsten Sinne der Definition.

Beispiel formatiert als JSON:

{
    "meta" {
        "success": false,
        "message": "Search yielded no results",
        "code": "NORESULTS"
    }
    "data": []
}

"Harte Fehler" hingegen werden mit einem Statuscode bedient, der für den Fehler empfohlen wird. Benutzer nicht eingeloggt? - 403 / 401. Falsche Eingabe? - 400. Serverfehler? - 50X. Und so weiter.

Auch hier ist es ein bisschen meinungsbasiert. Manche Leute wollen alle Fehler gleich behandeln, "harte Fehler" alles. Keine Suchergebnisse? Das ist ein 404! Auf der anderen Seite der Medaille, keine Suchergebnisse? - Das ist wie erwartet kein Fehler.

Ein weiterer wichtiger Faktor, den Sie berücksichtigen sollten, ist beispielsweise Ihre Architektur. wenn Sie mit Ihrer API mithilfe von JavaScript XHR-Anforderungen und jQuery oder AngularJS interagieren. Diese "harten Fehler" müssen mit einem separaten Rückruf behandelt werden, wohingegen die "weichen Fehler" mit dem "Erfolg" -Rückruf behandelt werden können. Nichts zu brechen, das Ergebnis ist immer noch "wie erwartet". Der clientseitige Code kann dann den Erfolgsstatus und den Code (oder die Nachricht) anzeigen. Und drucken Sie das an den Endbenutzer.

Es gibt zwei Aspekte einer API: den Aufwand, die API zu implementieren, und den Aufwand aller Clients, die API ordnungsgemäß zu verwenden.

Als Autor des Clients weiß ich, dass ich beim Senden einer Anfrage an einen Webserver möglicherweise eine Fehlermeldung (nie richtig mit dem Server gesprochen) oder eine Antwort mit einem Statuscode erhalte. Ich muss mit den Fehlern umgehen. Ich muss mit einer guten Antwort umgehen. Ich muss mit erwarteten, dokumentierten, "schlechten" Antworten umgehen. Ich muss damit umgehen, was sonst noch zurückkommt.

Beim Entwerfen der API sollten Sie sich ansehen, was für den Client am einfachsten zu verarbeiten ist. Wenn der Client eine wohlgeformte Anfrage sendet und Sie das tun können, worum Sie gebeten werden, sollten Sie eine Antwort im Bereich 200 geben (in einigen Fällen ist eine andere Zahl als 200 in diesem Bereich angemessen).

Wenn der Client fragt "gib mir alle Datensätze wie ..." und es gibt null, dann ist eine 200 mit Erfolg und einem Array von null Datensätzen völlig angemessen. Die Fälle, die Sie erwähnen:

"Anmeldung fehlgeschlagen" sollte normalerweise eine Zahl von 401 sein. "Datei konnte nicht gefunden werden" sollte eine Zahl von 404 sein. "Fehlender Parameter x" sollte eine Zahl von 500 sein (tatsächlich eine Zahl von 400, wenn der Server feststellt, dass die Anforderung fehlerhaft ist, und 500 wenn der Server durch meine Anfrage total verwirrt ist und keine Ahnung hat, was los ist). In diesen Fällen ist die Rückgabe von 200 sinnlos. Es bedeutet nur, dass ich als Autor eines Kunden nicht nur den Statuscode einsehen kann, sondern auch die Antwort studieren muss. Ich kann nicht einfach sagen "Status 200, großartig, hier sind die Daten".

Vor allem der "Parameter fehlt" - damit würde ich nie fertig werden . Es bedeutet, dass meine Anfrage falsch ist. Wenn meine Anfrage falsch ist, kann ich diese falsche Anfrage nicht rückgängig machen. Ich würde zunächst eine korrekte Anfrage senden. Jetzt bin ich gezwungen damit umzugehen. Ich bekomme eine 200 und muss prüfen, ob eine Antwort "parameter missing" vorliegt. Das ist schrecklich.

Am Ende gibt es ein Dutzend oder zwei Statuscodes für die Behandlung vieler verschiedener Situationen, und Sie sollten sie verwenden.