Если «ошибка проверки» означает, что в запросе есть какая-то ошибка клиента, используйте 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 .
Richardson и Ruby RESTful Web Services содержит очень полезное приложение о том, когда использовать различные коды ответов HTTP. Они говорят:
400 («Неверный запрос»)
Важность: высокая.
Это общее состояние ошибки на стороне клиента, используемое, когда другой код ошибки 4xx не подходит. Обычно используется, когда клиент представляет представление вместе с
PUT или POST запрос, и представление в правильном формате, но оно не делает
любое чувство. (стр. 381)
и
401 («Несанкционированный»)
Важность: высокая.
Клиент пытался работать с защищенным ресурсом, не предоставив надлежащие учетные данные для аутентификации. Возможно, он предоставил неверные учетные данные или не указал их вообще.
Учетные данные могут быть именем пользователя и паролем, ключом API или аутентификацией
маркер - что бы ни ожидала рассматриваемая служба. Обычно клиент делает
запросите URI и примите 401, чтобы он знал, какие учетные данные отправлять
и в каком формате. [...]