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

Ответ 1

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

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

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

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

и

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

Ответ 2

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

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

Ответ 3

Дубликат в базе данных должен быть 409 CONFLICT.

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

Я даю более длинное объяснение кодов 4xx здесь: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

Ответ 4

Вот он:

rfc2616 # section-10.4.1 - 400 Bad Request

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

rfc7231 # section-6.5.1 - 6.5.1. 400 Bad Request

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

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

rfc4918 - 11.2. 422 Непроцессная организация

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

Заключение

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

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

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

Ответ 5

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

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

<status> <code> 4 </code> <message> Диапазон дат недействителен </message> </status>

Ответ 6

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

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

Ответ 7

Что именно вы подразумеваете под "отказом проверки"? Что вы проверяете? Вы имеете в виду нечто вроде синтаксической ошибки (например, неверный XML)?

Если это так, я бы сказал, что 400 Bad Request - это, вероятно, правильная вещь, но, не зная, что именно вы "проверяете", это невозможно сказать.