Żądanie jest poprawnie zbudowane, ale nie przechodzi walidacji.
Kiedy go używać
Prawidłowy JSON z nieprawidłowymi wartościami, np. datą końcową wcześniejszą niż początkowa.
Typowe przyczyny i rozwiązania
422 oznacza, że serwer zrozumiał składnię, ale treść nie przechodzi walidacji: wymagane pole jest puste, e-mail ma błędny format, zakres dat jest odwrócony albo wskazane ID nie istnieje. FastAPI zwraca go przy każdym błędzie walidacji Pydantic, a Rails i Laravel – przy nieudanej walidacji modelu. Rails zwraca 422 także przy nieprawidłowym tokenie CSRF, co bywa zaskoczeniem.
Zwracaj w treści błędy na poziomie pól, żeby klient mógł pokazać je przy właściwych polach formularza, najlepiej w spójnym formacie, takim jak problem details z RFC 9457. Nie ponawiaj 422 bez zmiany danych. Zespoły spierają się o 400 kontra 422; wybierz jedną zasadę, np. 400 dla danych, których nie da się sparsować, i 422 dla danych poprawnie sformatowanych, ale nieprawidłowych, i stosuj ją wszędzie.
Błąd klienta (4xx)
Kody 4xx to błędy klienta: samo żądanie jest błędne, nieautoryzowane albo wskazuje na coś, czego nie ma. Ponowienie tego samego żądania nic nie da.
Jak to wygląda
HTTP/1.1 422 Unprocessable ContentJak go wysłać
| Node.js / Express | res.status(422).end() |
|---|---|
| Python / Flask | return '', 422 |
| nginx | return 422; |
Jak go sprawdzić
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/