Когда API должен выдавать код состояния 4xx (ошибка), а когда 5xx?

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

На сайте W3C написано:

Ошибка клиента 4xx Класс кода состояния 4xx предназначен для случаев, когда клиент допустил ошибку.

Это также говорит

Ошибка сервера 5xx Коды состояния ответа, начинающиеся с цифры "5", указывают на случаи, когда сервер знает, что он допустил ошибку или не может выполнить запрос.

Я понимаю, что если запрос синтаксически правильный, но логически неправильный, например, попытка создать объект с недопустимым значением для определенного свойства, тогда мой API должен выдать ошибку 5xx, потому что сервер ДЕЙСТВИТЕЛЬНО понял запрос , но обнаружил, что он недействителен. С другой стороны, мне сказали, что это должна быть ошибка 4xx (в частности, 400 Bad Request), потому что логическая ошибка была на стороне клиента, поскольку он в первую очередь отправил недопустимое значение.

Итак, какой код ошибки я ДОЛЖЕН сообщать?


http error-handling http-status-code-400 http-status-codes
person Che Kofif    schedule 04.06.2014    source источник
comment
Я всегда думал, что ошибка 4xx может быть исправлена ​​пользователем, а ошибка 5xx должна быть исправлена ​​администрацией (например, исключение на стороне сервера). Таким образом, отправка неправильного запроса должна быть в диапазоне 4xx.   -  person zero298    schedule 04.06.2014
comment
@zero298 Zero298 Я не думаю, что это официальное различие ... но это интересный способ взглянуть на это, спасибо.   -  person Che Kofif    schedule 05.06.2014
comment
Описание тега http-status-code-500 гласит: НЕ ИСПОЛЬЗУЙТЕ ЭТОТ ТЕГ. Это не имеет смысла для классификации вашего вопроса. Пожалуйста, прочитайте описания тегов, прежде чем использовать их для своих вопросов.   -  person Ken White    schedule 12.06.2014

Ответы (1)


arrow_upward
2
arrow_downward

Ошибка 5xx возникает, когда проблема на стороне сервера. Например, когда вы делаете запрос с помощью метода или протокола, который не понят сервером, когда прокси не отвечает и т. д. Если коротко: когда сервер не смог выполнить запрос.

В вашем примере более уместна ошибка 4xx, потому что инициатор запроса является источником проблемы. Более конкретно, ошибка «422 Unprocessable Entity» уместна, поскольку, как указано в RFC 4918 :

Код состояния 422 (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (поэтому код состояния 415 (Unsupported Media Type) не подходит), а синтаксис объекта запроса правильный (таким образом, 400 (Bad Request). ) недопустимый код состояния), но не смог обработать содержащиеся в нем инструкции.

По разным причинам некоторые разработчики API пытаются ограничиться набором из 3-5 кодов состояния, которые будут использоваться. В целом это делается для облегчения работы пользователей API, что звучит хорошо, но иногда такая философия может иметь более серьезные последствия.

Например, если я отправлю запрос в какой-либо API на добавление нового комментария, я ожидаю, что будут предоставлены некоторые вещи, например (но не ограничиваясь этим):

  • Запрос POST или отправьте мне статус 405, если нет.
  • Если комментарий был добавлен, я получу ответ 201 со ссылкой на мой новый комментарий в теле.

Что я получаю иногда?

  • Если метод запроса не POST, я получу ошибку 400.
  • Если запрос POST, я получу статус 200, а иногда и ссылку на мой новый комментарий.

Звучит запутанно? Для меня это так.

person Alexandru Guzinschi    schedule 11.06.2014