Ihr Fall: HTTP 400 ist aus REST-Perspektive der richtige Statuscode für Ihren Fall, da es syntaktisch falsch ist, sales_tax anstelle von tax zu senden, obwohl es ein gültiges JSON ist. Dies wird normalerweise von den meisten serverseitigen Frameworks durchgesetzt, wenn das JSON zu Objekten gemappt wird. Es gibt jedoch einige REST-Implementierungen, die den neuen key im JSON-Objekt ignorieren. In diesem Fall kann ein benutzerdefinierter content-type-Spezifikation erzwungen werden, um nur gültige Felder auf serverseitiger Seite zu akzeptieren.
Idealszenario für 422:
In einer idealen Welt ist 422 bevorzugt und im Allgemeinen akzeptabel als Antwort, wenn der Server den Inhaltstyp der Anforderungseinheit versteht und die Syntax der Anforderungseinheit korrekt ist, aber nicht in der Lage war, die Daten zu verarbeiten, weil sie semantisch fehlerhaft sind.
Situationen von 400 über 422:
Denken Sie daran, der Antwortcode 422 ist ein erweiterter HTTP (WebDAV) Statuscode. Es gibt immer noch einige HTTP-Clients / Front-End-Bibliotheken, die nicht darauf vorbereitet sind, 422 zu verarbeiten. Für sie ist es so einfach wie "HTTP 422 ist falsch, weil es nicht HTTP ist". Aus Sicht des Dienstes ist 400 nicht ganz spezifisch.
In der Enterprise-Architektur werden die Dienste hauptsächlich auf Dienstschichten wie SOA, IDM usw. bereitgestellt. Sie bedienen typischerweise mehrere Clients, die von sehr alten nativen Clients bis zu den neuesten HTTP-Clients reichen. Wenn einer der Clients kein HTTP 422 behandelt, besteht die Möglichkeit, den Client aufzufordern, ein Upgrade durchzuführen oder Ihren Antwortcode für alle auf HTTP 400 zu ändern. Meiner Erfahrung nach ist dies heutzutage sehr selten, aber immer noch möglich. Daher ist eine sorgfältige Untersuchung Ihrer Architektur immer erforderlich, bevor Sie sich für die HTTP-Antwortcodes entscheiden.
Um Situationen wie diese zu behandeln, verwenden die Dienstschichten normalerweise Versionierung oder richten Konfigurations-Flags ein, um strikte HTTP-Konformitätsclients zu senden 400 und senden 422 für den Rest von ihnen. Auf diese Weise bieten sie rückwärtskompatible Unterstützung für bestehende Verbraucher, ermöglichen aber gleichzeitig den neuen Clients, HTTP 422 zu konsumieren.
Das neueste Update zu RFC7321 besagt:
Der 400 (Bad Request) Statuscode zeigt an, dass der Server die Anforderung nicht verarbeiten kann oder
wird aufgrund eines als Clientfehler wahrgenommenen Problems nicht verarbeiten (z. B. fehlerhafte Anforderungssyntax, ungültiges Anforderungsmeldungs-Framing oder irreführende Anforderungsroute).
Dies bestätigt, dass Server HTTP 400 für ungültige Anfragen senden können. 400 bezieht sich nicht mehr nur auf einen Syntaxfehler, jedoch ist 422 immer noch eine legitime Antwort, sofern die Clients sie verarbeiten können.
