Ошибка 422: запрос дошёл, но данные не приняты — что проверить

Ошибка 422 Unprocessable Content означает, что сервер понимает формат тела запроса и его синтаксис, но не может выполнить содержащиеся в нём инструкции. Начните с тела ответа: оно может назвать отклонённое поле или нарушенное правило, даже когда интерфейс показывает только «Не удалось сохранить».

Если 422 возникает при отправке формы или вызове API, перезапуск хостинга обычно не объясняет отказ. Нужно сопоставить конкретный запрос с требованиями endpoint и найти различие между отправленными данными и тем, что принимает сервер.

Что означает 422 и чего код не доказывает

Такое значение закреплено в RFC 9110, раздел 15.5.21. В старых документах и сообщениях встречается название Unprocessable Entity; при диагностике ориентируйтесь на число 422 и контракт конкретного API.

По стандартному смыслу 415 относится к неподдерживаемому формату содержимого, а 422 — к невозможности обработать его инструкции при понятном формате и корректном синтаксисе. Но приложение может использовать коды иначе: один HTTP-статус не называет ни поле, ни внутренний компонент, который сформировал ответ.

422 не доказывает падение всего сайта и не гарантирует, что ошибка именно в действиях посетителя. После релиза frontend может отправлять старую структуру, а backend — требовать новое поле; в таком случае исправление нужно в коде или контракте.

Диагностика: от ответа к конкретному полю

1. Найдите запрос, который получил отказ

Откройте инструменты разработчика браузера и вкладку Network («Сеть»). На тестовом контуре повторите действие и выберите запрос с кодом 422: смотрите фактический адрес, метод и время, а не только URL страницы формы.

Не путайте основной POST-запрос с загрузкой страницы или предварительным OPTIONS. Если запрос вообще не отправился, ошибка находится раньше HTTP-обмена и этот порядок диагностики пока не применим.

2. Прочитайте тело ответа

Во вкладках Response или Preview найдите сообщение, код правила и путь к данным. Названия вроде errors, detail, field или loc зависят от приложения: единого обязательного JSON-формата для 422 нет.

Условный ответ может выглядеть так:

{
  "errors": [
    {
      "field": "items[0].quantity",
      "code": "positive_integer_required"
    }
  ]
}

Это вымышленный пример структуры, а не обещание конкретного API. Он направляет проверку к quantity первого элемента массива: нужно выяснить, отправлено ли там положительное целое число, строка, ноль или пустое значение.

Если вместо подробностей пришла HTML-страница либо общее сообщение, не угадывайте правило. Зафиксируйте время с часовым поясом и идентификатор запроса, если он есть: дальше понадобится связать запрос с логами прокси и приложения.

3. Сравните реальное тело с контрактом endpoint

Откройте Payload и действующую документацию API. Проверяйте данные после преобразований JavaScript: видимое значение поля может отличаться от отправленного.

Сверяйте по порядку:

1. Имя и путь. Поле находится на ожидаемом уровне вложенности; массив не заменён объектом.
2. Наличие. Отсутствующий ключ, null и пустая строка могут иметь разный смысл.
3. Тип и диапазон. Число не превратилось в строку, значение входит в разрешённые границы.
4. Допустимые значения. Статус или единица измерения совпадают с перечислением в контракте.
5. Связи между полями. Например, конец периода не раньше начала, а выбранный вариант разрешён для указанной категории.

Не добавляйте поле наугад только ради исчезновения ошибки. Если контракт и ответ противоречат друг другу, передайте расхождение владельцу API; при проблеме совместимости пригодится проверка контракта интеграции.

4. Проверьте одну гипотезу за раз

На изолированном стенде возьмите минимальный корректный запрос из документации и сравните его с неработающим. Меняйте только одно предполагаемое расхождение: иначе успешный ответ не покажет, какое изменение помогло.

Например, если контракт требует целое число, сравните {"quantity":"2"} и {"quantity":2}. Сервер может преобразовывать строку автоматически или отклонять её — результат определяется его правилами, а не внешним сходством JSON.

Не повторяйте запрос создания заказа или платежа в production для эксперимента. Сам код отказа не заменяет проверку отсутствия побочных действий; используйте тестовую среду и предусмотренный API механизм защиты от дублей.

5. Если поле допустимо, проверьте серверную ветку

Когда очищенный пример соответствует контракту, найдите в логах правило, сформировавшее 422. Сравните версии клиента и сервера, условия обязательности полей и ответ внешней интеграции, если приложение передаёт её отказ пользователю.

Не отключайте валидацию целиком. Исправьте конкретное расхождение и добавьте регрессионную проверку: допустимый ввод проходит, недопустимый отклоняется с понятным сообщением.

Как убедиться, что исправление сработало

Проверьте не только исчезновение 422, но и ожидаемый результат операции на стенде: запись сохранилась, данные верны, повторный запуск не создаёт дубль. Интерфейс должен показать ошибку рядом с нужным полем и сохранить остальные введённые значения.

Для журнала диагностики достаточно метода, безопасного адреса endpoint, времени, версии релиза, кода правила и обезличенного примера. Удалите Cookie, Authorization, токены, пароли и персональные данные; полный HAR или скопированный запрос нельзя пересылать без очистки.

Что контролировать после устранения отказа

Web-Puls помогает регулярно проверять доступность публичного URL и время ответа. Обычная проверка страницы не заполняет форму и не подтверждает, что сервер принимает конкретные данные; для этого нужен отдельный тест сценария на безопасном контуре.

Если 422 остаётся, а доступ к правилам backend или логам ограничен, можно отправить заявку на профессиональную поддержку. Укажите публичный URL, шаги, время и часовой пояс, ожидаемый результат и очищенное сообщение об ошибке: специалист оценит задачу и предложит формат работ.