Backend-Ausnahmebehandlung für REST-App - sollten wir 4XX Fehler oder 200 mit Fehlermarkierung zurückgeben

Question

Ich arbeite an großen Web-App, und innerhalb des Projekts entwickle ich eine REST-App für externe Kunden. Ich denke, dass diese Frage nicht viel mit der spezifischen Technologie zu tun hat, die ich verwende, aber nur für den Fall - es ist Django.

Wir haben ein Abkommen mit dem Entwicklungsteam, die Ressourcen immer ein Standard-JSON-Objekt vom Typ

{'success': <value>, 
'object': <value> 
'error_msg': <value>, 
} 

zusammen mit dem Status zurückzukehren REST (200, 201, 403, etc ....)

Beispiele für Django Umsetzung:

return Response({'success': true, 
       'object': ..., 
       'error_msg': ...}, 
       status=status.HTTP_200_OK) 

der success Parameter true für den erfolgreichen Einsatz der Ressource zugeordnet ist, und false sonst.

Nun liegt die ganze Frage hier in was sollte in status Parameter übergeben werden, wenn etwas Schlimmes passiert - entsprechende 4XX-Code oder 200?. Das Entwicklerteam schlägt vor, IMMER HTTP_200_OK zu verwenden, wenn einfach etwas Schlimmes passiert ist, weisen Sie einfach success zu. Die error_msg enthält detaillierte Fehlermeldung im Ausnahmefall.

So sind die beiden Alternativen, unter denen kann ich nicht das Richtige sieht wie folgt aus

return Response({'success': false, 
        'object': ..., 
        'error_msg': 'Details regarding the error'}, 
        status=status.HTTP_400_BAD_REQUEST) 

vs wählen:

return Response({'success': false, 
       'object': ..., 
       'error_msg': 'Details regarding the error'}, 
       status=status.HTTP_200_OK) 

(in beiden Fällen success wird false gleich, so in beiden. Fälle der Entwickler wird wissen, dass etwas schief gelaufen ist, indem Sie success ohne zu überprüfen status)
Aber die Existenz von verschiedenen error codes lässt mich mit unangenehmen Zweifeln darüber, dass mir etwas fehlt, WARUM Leute unterschiedliche Fehlercodes gefunden haben. Und in welchen Situationen kann mein Projekt Probleme auftreten, wenn es immer den gleichen 200 Statuscode zurückgibt. Nachdem ich Tonnen von Materialien gelesen habe, habe ich keine materielle Erklärung, warum das Angeben von geeigneten Fehlerstatuscodes den Ansatz des Zurückgebens von 200 Status übertreffen könnte.

Answer 1

HTTP-Codes sind meiner Meinung nach eine gute Möglichkeit, Informationen über das Ergebnis einer Operation aus den folgenden Gründen zu bekommen:

• Beide maschinen- und menschenlesbaren (zumindest von den Entwicklern) sind.
• Sie sind in jede HTTP-Transaktion integriert, daher implementiert jede Bibliothek Mechanismen, um mit ihnen umzugehen.
• Das Repertoire der Fehlercodes ist "standardisiert" und jeder weiß, wie man damit umgeht, und es deckt viele häufige Fälle ab (das DRF-Framework verwendet automatisch einige von diesen, wie 400, 403 oder 405).
• Indem Sie sie ignorieren, erhöhen Sie den Arbeitsaufwand, den Sie selbst implementieren müssen.

Natürlich könnten sie für bestimmte Fälle nicht ausreichen. Angenommen, Sie erhalten einen 400-Code, wenn Sie mehrere Felder an Ihre API senden.Wenn Sie wissen möchten, welche ungültig sind und warum, benötigen Sie immer noch den Wert Ihrer error_msg, aber der 400-Code vereinfacht immer noch einen Großteil Ihrer Logik, da Sie viele andere Gründe herausfiltern können, warum die Anfrage nicht erfolgreich war (403, 405 ...).

Zu Ihrer Frage:

Und In welchen Situationen mein Projekt Schwierigkeiten konfrontiert, wenn es immer gleich 200

Nun kehrt, wenn Sie die Dinge richtig implementieren, alle Fehler zu verlassen, um die Handhabung Antwortdatum, es sollte nie irgendwelche Probleme verursachen, aber wie bereits früher argumentiert, fühle ich mich wie dies die Komplexität der Aufgabe erhöht.

Bitte beachten Sie, dass dies nur meine zwei Cent sind, und es könnte andere Meinungen mit besseren Argumenten für den umgekehrten Fall geben.