La requête est bien formée mais échoue à la validation.
Quand l’utiliser
JSON valide avec des valeurs invalides, comme une date de fin antérieure à la date de début.
Causes courantes et solutions
422 signifie que le serveur a compris la syntaxe, mais que le contenu échoue à la validation : un champ obligatoire est vide, un e-mail est mal formé, une plage de dates est inversée ou un ID référencé n’existe pas. FastAPI le renvoie pour chaque erreur de validation Pydantic, et Rails et Laravel l’utilisent quand la validation d’un modèle échoue. Rails renvoie aussi 422 pour un jeton CSRF invalide, ce qui surprend.
Renvoyez des erreurs par champ dans le corps pour que le client puisse les afficher à côté des bons champs de saisie, idéalement dans un format cohérent comme les problem details de la RFC 9457. Ne réessayez pas un 422 sans modifier les données. Les équipes ne s’accordent pas sur le choix entre 400 et 422 ; choisissez une règle, par exemple 400 pour une entrée impossible à parser et 422 pour une entrée bien formée mais invalide, et appliquez-la partout.
Erreur client (4xx)
Les codes 4xx sont des erreurs client : la requête elle-même est incorrecte, non autorisée ou vise quelque chose qui n’existe pas. Renvoyer la même requête ne servira à rien.
À quoi ça ressemble
HTTP/1.1 422 Unprocessable ContentComment l’envoyer
| Node.js / Express | res.status(422).end() |
|---|---|
| Python / Flask | return '', 422 |
| nginx | return 422; |
Comment le vérifier
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/