Какой соответствующий код состояния HTTP возвращается службой REST API при сбое проверки?


394

В настоящее время я возвращаю 401 Unauthorized всякий раз, когда я сталкиваюсь с ошибкой проверки в моем приложении REST API на основе Django / Piston . Изучив реестр кодов состояния HTTP, я не уверен, что это подходящий код для сбоя проверки, что вы порекомендуете?

  • ошибка 400, неверный запрос
  • 401 Несанкционированный
  • 403 Запрещено
  • 405 метод не разрешен
  • 406 неприемлемо
  • 412 Не выполнено предварительное условие
  • 417 Ожидание не удалось
  • 422 необработанного объекта
  • 424 Неудачная зависимость

Обновление : «Ошибка проверки» выше означает ошибку проверки данных на уровне приложения, т. Е. Неправильно указанную дату и время, поддельный адрес электронной почты и т. Д.


2
Проверьте этот ответ: stackoverflow.com/a/2657624/221612
Кенни Мейер

3
Fwiw, ссылка Кенни предлагает код 422, как ответ Джима теперь делает ниже . #TheMoreYouKnow #SavingYouAClick
ruffin

Я думаю, что 401 более понятен.
знак

Ответы:


298

Если «ошибка проверки» означает, что в запросе есть какая-то ошибка клиента, используйте HTTP 400 (неверный запрос). Например, если предполагается, что URI имеет дату ISO-8601, и вы обнаружите, что она имеет неправильный формат или относится к 31 февраля, тогда вы вернете HTTP 400. То же самое, если вы ожидаете правильно сформированный XML в теле объекта и это не в состоянии разобрать.

(1/2016): За последние пять лет более специфичный HTTP 422 (Unprocessable Entity) WebDAV стал очень разумной альтернативой HTTP 400. См., Например, его использование в JSON API . Но учтите, что HTTP 422 не превратился в HTTP 1.1, RFC-7231 .

RESTful Web Services Ричардсона и Руби содержат очень полезное приложение о том, когда использовать различные коды ответов HTTP. Они говорят:

400 («Неверный запрос»)
Важность: высокая.
Это общее состояние ошибки на стороне клиента, используемое, когда другой код ошибки 4xx не подходит. Это обычно используется, когда клиент отправляет представление вместе с запросом PUT или POST, и представление имеет правильный формат, но это не имеет никакого смысла. (стр. 381)

а также:

401 («Несанкционированный»)
Важность: высокая.
Клиент пытался работать на защищенном ресурсе, не предоставив надлежащие учетные данные для аутентификации. Возможно, он предоставил неверные учетные данные или не указал их вообще. Учетные данные могут быть именем пользователя и паролем, ключом API или токеном аутентификации - чего бы ни ожидала рассматриваемая служба. Обычно клиент делает запрос на URI и принимает 401, просто чтобы знать, какие учетные данные отправлять и в каком формате. [...]


3
Но, вероятно, если недопустимый формат URI, 404 может быть более подходящим.
Мана

11
Как утверждает @ReWrite, я также думаю, что 422 лучше для ошибок проверки.
Panteo

11
Я бы сказал, что это неправильно. 400 Bad Request используется, когда в запросе синтаксически что-то не так. Я бы сказал, что ReWrite правильно рекомендует 422, что касается содержания запроса.
Стейн де Витт

3
@ Кендзи, да, 401 («Несанкционированный»): «Возможно, он предоставил неверные учетные данные ...» означает неправильный пользователя и / или пароль.
Раззинтаун

4
Ошибки @JimFerrans 400 предназначены для случаев, когда синтаксис указан неверно. Ошибки 401 возникают, в частности, если я пытаюсь получить доступ к странице, на которой мне нужно войти, чтобы получить доступ, и я не вошел в систему вообще. 422 ошибки для того, где синтаксис правильный, но сервер отказывает в обслуживании. Неверное имя пользователя / пароль - правильный синтаксис (не ошибка 400), и я не пытаюсь получить доступ к странице, для которой мне нужно войти, потому что я получаю доступ к самой странице входа (не ошибка 401). Ошибка 401 должна использоваться для чего-то вроде страницы настроек, доступ к которой может получить только пользователь
Zachary Weixelbaum

98

Из RFC 4918 (а также задокументировано по адресу http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml ):

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


6
Я бы порекомендовал 422 - Unprocessable Entity для ошибок проверки более 400
Неверный


19

Вот:

rfc2616 # section-10.4.1 - 400 Bad Request

Сервер не может понять запрос из-за неправильного синтаксиса . Клиент НЕ ДОЛЖЕН повторять запрос без изменений.

rfc7231 # section-6.5.1 - 6.5.1. ошибка 400, неверный запрос

Код состояния 400 (неверный запрос) указывает на то, что сервер не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента (например, синтаксис искаженного запроса, кадрирование неверного сообщения запроса или обманчивая маршрутизация запроса) .

Относится к неправильным (не хорошо сформированным) случаям!

rfc4918 - 11,2. 422 необработанного объекта

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

Вывод

Основное правило: [_] 00 охватывает наиболее общий случай и случаи, которые не охватываются указанным кодом.

422 соответствует наилучшей ошибке проверки объекта (именно моя рекомендация :)
Что касается семантически ошибочного - подумайте о чем-то вроде проверки «Это имя пользователя уже существует».

400 неправильно используется для проверки объекта


9

Я бы сказал, что технически это может быть не HTTP-сбой, поскольку ресурс (предположительно) был правильно задан, пользователь прошел аутентификацию и не было операционного сбоя (однако даже в спецификации есть некоторые зарезервированные коды, такие как 402 Payment Required, которые не ' Строго говоря, это также связано с HTTP, хотя было бы целесообразно иметь его на уровне протокола, чтобы любое устройство могло распознать условие).

Если это действительно так, я бы добавил поле статуса к ответу с ошибками приложения, например

<status> <code> 4 </ code> <message> Недопустимый диапазон дат </ message> </ status>


1

Немного больше информации о семантике этих ошибок в RFC 2616 , который документирует HTTP 1.1.

Лично я бы, наверное, использовал 400 Bad Request, но это только мое личное мнение без какой-либо фактической поддержки.


0

Что именно вы подразумеваете под «провалом валидации»? Что вы проверяете? Вы имеете в виду что-то вроде синтаксической ошибки (например, неправильно сформированный XML)?

Если это так, я бы сказал, что «400 плохих запросов», вероятно, правильно, но не зная, что именно вы «проверяете», невозможно сказать.


Что делать, если мы пытаемся подтвердить некоторые бизнес-проверки или правила.
Metalhead
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.