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

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

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

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

Википедия:

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

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

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

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

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

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

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

Из RFC 4918 :

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

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

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

Если проблема в том, что, как указано в вопросе, имя пользователя / адрес электронной почты уже существует, вы можете использовать 409 Conflict [ 2 ] с описанием конфликта и подсказкой о том, как его исправить (в данном случае, «выберите другое имя пользователя / адрес электронной почты "). Однако в спецификации, как написано, 403 Forbidden [ 3 ] также может использоваться в этом случае, несмотря на аргументы о HTTP-авторизации.

412 Precondition Failed [ 4 ] используется, когда заголовок запроса предварительного условия (например If-Match), который был предоставлен клиентом, оценивается как false. То есть клиент запросил что-то и предоставил предварительные условия, прекрасно зная, что эти предварительные условия могут потерпеть неудачу. 412 никогда не должны возникать на клиенте неожиданно и не должны быть связаны с объектом запроса как таковым .

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

2.3.2 418 Я чайник

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

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