Код ответа REST для неверных данных

Question

Какой код ответа необходимо передать клиенту в случае следующих сценариев?

1. Недопустимые данные, переданные при регистрации пользователя, например неправильный формат электронной почты
2. Имя пользователя / электронная почта уже существует

Я выбрал 403. Я также обнаружил, что можно использовать следующее.

Википедия:

412 Предварительное условие не выполнено: сервер не соответствует ни одномуиз предварительных условий, которые запрашивающая сторона ставит на запрос

Предложите код, если я должен использовать другой, чем 403.

Answer 1

400 - лучший выбор в обоих случаях. Если вы хотите дополнительно уточнить ошибку, вы можете либо изменить фразу причины, либо добавить текст для объяснения ошибки.

412 - Не выполнено предварительное условие для условных запросов при использовании даты последнего изменения и ETags.

403 - Запрещено используется, когда сервер желает запретить доступ к ресурсу.

Единственный возможный выбор - 422. Необработанный объект.

Answer 2

Я бы порекомендовал 422. Он не является частью основной спецификации HTTP, но он определяется общедоступным стандартом (WebDAV) и должен обрабатываться браузерами так же, как и любой другой код состояния 4xx.

С RFC 4918 :

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

Answer 3

Если запрос не может быть правильно обработан (включая объект / тело запроса), соответствующий ответ будет 400 Плохой запрос [ 1 ].

RFC 4918 гласит, что 422 Unprocessable Entity применимо, когда объект запроса синтаксически правильно сформирован, но семантически ошибочен.Поэтому, если объект запроса искажен (например, неправильный формат электронной почты), используйте 400;но если это просто не имеет смысла (например, @example.com), используйте 422.

Если проблема в том, что, как указано в вопросе, имя пользователя / адрес электронной почты уже существует, вы можете использовать 409Конфликт [ 2 ] с описанием конфликта и подсказкой о том, как его исправить (в данном случае «выберите другое имя пользователя / адрес электронной почты»).Однако в спецификации, как написано, 403 Forbidden [ 3 ] также может использоваться в этом случае, несмотря на аргументы об HTTP-авторизации. [ 4 ] используется, когда заголовок запроса предварительного условия (например, If-Match), который был предоставлен клиентом , оценивается как ложный.То есть клиент запросил что-то и предоставил предварительные условия, прекрасно зная, что эти предварительные условия могут потерпеть неудачу.412 никогда не должны возникать на клиенте неожиданно и не должны быть связаны с объектом запроса per se .

Answer 4

Забавно возвращать 418 I'm a teapot запросам, которые явно созданы или являются вредоносными и «не могут быть выполнены», например, при неудачной проверке CSRF или пропущенных свойствах запроса.

2.3.2 418 Я чайник

Любая попытка заваривать кофе с чайником должна привести к ошибке код "418 Я чайник". Полученное тело сущности МОЖЕТ быть коротким и Толстый.

Чтобы это было достаточно серьезно, я ограничиваю использование смешных кодов ошибок конечными точками RESTful, которые не предоставляются непосредственно пользователю.