Code d'état HTTP correct sur une mauvaise entrée

Quel est le code de réponse HTTP optimal lorsque vous ne signalez pas 200 (tout est OK) mais une erreur d'entrée?

Par exemple, vous soumettez des données au serveur, et il répondra que vos données sont fausses

l'utilisation 500ressemble plus à un problème de serveur l'
utilisation 200d'un texte de réponse d'avertissement / d'erreur est mauvaise (autoriser la mise en cache et tout n'est pas OK)
utiliser 204et ne renvoyer rien, est peut-être bon (mais bien pris en charge?) l'
utilisation 404est incorrecte si le chemin demandé (script) est disponible et au bon endroit

Nous avons eu le même problème lors de la création de notre API. Nous recherchions un code d'état HTTP équivalent à un InvalidArgumentException. Après avoir lu l'article source ci-dessous, nous avons fini par utiliser 422 Unprocessable Entityquels états:

Le code d'état 422 (Unprocessable Entity) signifie que le serveur comprend le type de contenu de l'entité de demande (donc un code d'état 415 (Unsupported Media Type) est inapproprié) et que la syntaxe de l'entité de demande est correcte (donc un 400 (Bad Request ) le code d'état est inapproprié) mais n'a pas pu traiter les instructions contenues. Par exemple, cette condition d'erreur peut se produire si un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.

source: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm

Les codes commençant par 4 (4xx) sont destinés aux erreurs du client. Peut-être que 400 (Bad Request) pourrait convenir à ce cas? La définition dans http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html dit:

"La demande n'a pas pu être comprise par le serveur en raison d'une syntaxe mal formée. Le client NE DEVRAIT PAS répéter la demande sans modifications."

En plus de la spécification RFC, vous pouvez également voir cela en action. Consultez les réponses Twitter.

https://developer.twitter.com/en/docs/ads/general/guides/response-codes

409 Conflict pourrait être une solution acceptable.

Selon: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

La demande n'a pas pu être exécutée en raison d'un conflit avec l'état actuel de la ressource. Ce code n'est autorisé que dans les situations où l'on s'attend à ce que l'utilisateur soit en mesure de résoudre le conflit et de soumettre à nouveau la demande. Le corps de la réponse DEVRAIT inclure suffisamment d'informations pour que l'utilisateur reconnaisse la source du conflit. Idéalement, l'entité de réponse inclurait suffisamment d'informations pour que l'utilisateur ou l'agent utilisateur puisse résoudre le problème; cependant, cela peut ne pas être possible et n'est pas obligatoire.

La doc continue avec un exemple:

Les conflits sont plus susceptibles de se produire en réponse à une demande PUT. Par exemple, si le contrôle de version était utilisé et que l'entité PUT incluait des modifications apportées à une ressource qui sont en conflit avec celles effectuées par une demande antérieure (tierce), le serveur peut utiliser la réponse 409 pour indiquer qu'il ne peut pas terminer la demande . Dans ce cas, l'entité de réponse contiendrait probablement une liste des différences entre les deux versions dans un format défini par la réponse Content-Type.

Dans mon cas, je voudrais METTRE une chaîne, qui doit être unique, dans une base de données via une API. Avant de l'ajouter à la base de données, je vérifie qu'il n'est pas déjà dans la base de données.

Si c'est le cas, je reviendrai "Error: The string is already in the database", 409.

Je crois que c'est ce que voulait l'OP: un code d'erreur adapté lorsque les données ne satisfont pas aux critères du serveur.

Selon le scénario ci-dessous,

Disons que quelqu'un fait une demande à votre serveur avec des données au format correct, mais qui ne sont tout simplement pas de «bonnes» données. Par exemple, imaginez que quelqu'un ait publié une valeur String sur un point de terminaison d'API qui attendait une valeur String; mais, la valeur de la chaîne contenait des données qui étaient sur la liste noire (ex. empêchant les gens d'utiliser "mot de passe" comme mot de passe). alors le code d'état pourrait être 400 ou 422?

Jusqu'à présent, j'aurais renvoyé une "400 Bad Request", ce qui, selon le w3.org, signifie:

La demande n'a pas pu être comprise par le serveur en raison d'une syntaxe incorrecte. Le client NE DEVRAIT PAS répéter la demande sans modifications.

Cette description ne correspond pas tout à fait aux circonstances; mais, si vous consultez la liste des codes d'état HTTP de base définis dans le protocole HTTP / 1.1, c'est probablement votre meilleur pari.

Récemment, cependant, un membre de mon équipe de développement m'a fait remarquer que les API populaires commencent à utiliser des extensions HTTP pour obtenir plus de précision dans leurs rapports d'erreurs. Plus précisément, de nombreuses API, comme Twitter et Recurly, utilisent le code d'état "422 Entité non traitable" tel que défini dans l'extension HTTP pour WebDAV. Le code d'état HTTP 422 indique:

Le code d'état 422 (Unprocessable Entity) signifie que le serveur comprend le type de contenu de l'entité de demande (donc un code d'état 415 (Unsupported Media Type) est inapproprié) et que la syntaxe de l'entité de demande est correcte (donc un 400 (Bad Request ) le code d'état est inapproprié) mais n'a pas pu traiter les instructions contenues. Par exemple, cette condition d'erreur peut se produire si un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.

Pour revenir à notre exemple de mot de passe ci-dessus, ce code d'état 422 semble beaucoup plus approprié. Le serveur comprend ce que vous essayez de faire; et il comprend les données que vous soumettez; il ne permettra tout simplement pas que ces données soient traitées.

404 - Not Found - peut être utilisé pour L'URI demandé n'est pas valide ou la ressource demandée, comme un utilisateur, n'existe pas.