Что соответствующий код состояния HTTP должен возвратить сервисом API REST для отказа проверки?
Я в настоящее время возвращаю 401 Несанкционированный каждый раз, когда я встречаюсь, отказ проверки в моем Django/Piston основывал REST приложение API. Взглянув на Реестр кода состояния HTTP, я не убежден, что это - соответствующий код для отказа проверки, что Вы все рекомендуете?
- 400 плохих запросов
- 401 Несанкционированный
- 403 Запрещенных
- 405 методов, не позволенных
- 406 не приемлемый
- 412 неудавшихся предварительных условий
- 417 неудавшихся ожиданий
- 422 объекта Unprocessable
- 424 неудавшихся зависимости
Обновление: "Отказ проверки" выше средств отказ подтверждения правильности данных прикладного уровня, т.е. неправильно указанная дата и время, поддельный адрес электронной почты и т.д.
4 ответа
Если "ошибка валидации" означает, что в запросе имеется некоторая ошибка клиента, то используйте HTTP 400 (Bad Request). Например, если URI должен иметь ISO-8601 дата и вы обнаружите, что он находится в неправильном формате или относится к 31 февраля, то вы вернете HTTP 400. То же самое, если вы ожидаете хорошо сформированный XML в теле сущности и он не может быть разобран.
(1/2016): За последние пять лет WebDAV более специфический HTTP 422 (Unprocessable Entity) стал очень разумной альтернативой HTTP 400. См., например, его использование в JSON API. Но обратите внимание, что HTTP 422 не , а превратил его в HTTP 1.1, RFC-7231.
Richardson и Ruby's RESTful Web Services содержат очень полезное приложение о том, когда использовать различные коды ответа HTTP. Они говорят:
400 ("Плохой запрос")
Важность: Высоко.
Это общий статус ошибки на стороне клиента, используемый, когда другой код ошибки 4xx не подходит. Обычно используется, когда клиент отправляет представление вместе с PUT или POST запрос, и представление в правильном формате, но оно не делает любой смысл. (p. 381)
and:
401 (“Unauthorized”)
Importance: Высоко.
Клиент пытался работать на защищенном ресурсе без предоставления надлежащих учетных данных для аутентификации. Возможно, он предоставил неверные учетные данные, или вообще их не предоставил. Учетные данные могут быть именем пользователя и паролем, API ключом или аутентификацией. жетон - чего бы ни ожидала данная служба. Обычно клиент делает запрос на URI и принять 401 только для того, чтобы он знал, какие полномочия нужно отправить. и в каком формате. [...]
Я бы сказал, что технически это может быть и не сбой HTTP, так как ресурс был (предположительно) правильно указан, пользователь был аутентифицирован, и не было никакого сбоя в работе (однако, даже спецификация включает некоторые зарезервированные коды, такие как 402 Payment Required, которые, строго говоря, тоже не связаны с HTTP, хотя, возможно, было бы желательно, чтобы это было на уровне протокола, чтобы любое устройство могло распознать условие).
Если это действительно так, я бы добавил в ответ поле состояния с ошибками приложения, например
4
Что именно вы имеете в виду под "неудачей проверки"? Что вы подразумеваете под "валидацией"? Вы имеете в виду что-то вроде синтаксической ошибки (например, некорректный XML)?
Если это так, то я бы сказал, что 400 Bad Request, вероятно, правильно, но не зная, что вы "валидируете", невозможно сказать.
.Немного больше информации о семантике этих ошибок есть в RFC 2616, в документах HTTP 1.1.
Лично я бы, вероятно, использовал 400 Плохой запрос, но это только мое личное мнение без какой-либо фактической поддержки.