Является ли статус HTTP 422 подходящим для записей, которые не подтверждают однозначность?

Я делал это много раз (и видел, как это делают многие люди), но я начинаю задаваться вопросом, подходит ли это:

if @record.save
  # status 200
else
  # failure of validations => status 422
end

Теперь я вижу, что 422 unprocessable entity означает, что запрос был корректным, но не семантически правильным. Как я понял, ошибка проверки не может быть семантической ошибкой.

Примечание: Я говорю о проверках уникальности, поэтому я не уверен, что это квалифицируется как ошибка пользователя, как в этом вопросе: Какой подходящий код состояния HTTP для возврата службой API REST для отказа проверки?

Подводя итог: следует ли прекратить использование статуса 422? Если да, то что я должен использовать вместо этого?

Ответы

Ответ 1

NB: попытался сделать подробный ответ ниже, чтобы сделать один, но это кажется невозможным, поэтому я отвечу здесь.

Я думаю, что использование ошибок 422 для проверки достоверно.

  • Webdav RFC не говорит, что 422 означает "семантические ошибки", он говорит, что сервер "не смог обработать содержащиеся инструкции" (см. http://tools.ietf.org/html/rfc4918#section-11.2). "Семантические ошибки" просто приведены в качестве примера использования.

  • 500 зарезервировано для "неожиданного условия, которое мешало ему выполнить запрос" (http://tools.ietf.org/html/rfc2616#section-10.5.1).

500 обычно зарезервирован для реальных ошибок, например. вещи, которые не обрабатываются вообще в вашем коде, например, сбои. Ошибки проверки обрабатываются, они не являются "неожиданными", и клиент должен изменить запрос, чтобы его можно было обработать (или нет). В этом смысле клиент сделал ошибку (например, отправка неверного адреса электронной почты приведет к ошибке проверки, но, очевидно, это не ошибка сервера, правда?).

Большинство API, которые я видел, используют для таких случаев 400 или 422. Может быть, нет ни одного истинного ответа на этот вопрос, но сказать, что 500 - это очевидный способ пойти, казалось мне неправильным.

Надеюсь, что это поможет.

Ответ 2

Я согласен с jbbarth, что это не так просто, как 422 vs 500.

422 хорош для ошибок проверки, но вы также не хотите ловить ошибки db.

Это шаблон, который я использую:

if @record.invalid?
  # failure of validations => status 422
elsif @record.save
  # status 200
else
  # failure when saving => status 500
end

Ответ 3

В то время как возвращение 422 в порядке, я бы сказал, что неудачные проверки уникальности должны возвращать конфликт 409.

Ответ 4

Я понимаю, что когда HTTP-запрос был прав, но вы проиграли на стороне сервера - по какой-либо причине - тогда вы должны выбросить ошибку 5xx, указывая на наличие проблемы с сервером. Если вы не можете указать его дальше, просто 500 обычно достаточно хорош.

Если это не ошибка клиентов, но что-то еще (что повлияло на влияние клиента) не позволило сохранить запись, то это ошибка сервера, а не (клиентская) ошибка в смысле HTTP-связи.