Какой код ответа должен быть передан клиенту в случае следующих сценариев?
Я выбрал 403. Я также нашел следующее, что, по-моему, можно использовать.
Википедия:
412 Условие не выполнено: Сервер не отвечает одному из предварительных условий, в которых запрашивающий положить на запрос
Предложите код, если я должен использовать, кроме 403.
400 - лучший выбор в обоих случаях. Если вы хотите уточнить ошибку, вы можете либо изменить фразу причины, либо включить тело, чтобы объяснить ошибку.
412 - Сбой предварительного условия используется для условных запросов при использовании даты последнего изменения и ETags.
403 - Запрещено использовать, когда сервер хочет предотвратить доступ к ресурсу.
Единственным возможным выбором является 422 - Непроцессная сущность.
Я бы порекомендовал 422. Это не часть основной спецификации HTTP, но она определяется общедоступным стандартом (WebDAV), и она должна обрабатываться браузерами так же, как и любой другой код состояния 4xx.
Из RFC 4918:
Код состояния 422 (необработанная сущность) означает, что сервер понимает тип содержимого объекта запроса (следовательно, код статуса 415 (неподдерживаемый тип носителя) является неуместным), и синтаксис объекта запроса является правильным (таким образом, 400 (Bad Request) неуместен), но не смог обработать содержащиеся инструкции. Например, это условие ошибки может возникнуть, если тело запроса XML содержит правильно сформированные (т.е. Синтаксически правильные), но семантически ошибочные инструкции XML.
Если запрос не может быть правильно разобран (включая объект/тело запроса), соответствующий ответ 400 Bad Request [1].
RFC 4918 утверждает, что 422 Unprocessable Entity применим, когда объект запроса синтаксически корректен, но семантически ошибочен. Поэтому, если объект запроса искажен (например, плохой формат электронной почты), используйте 400; но если это просто не имеет смысла (например, @example.com), используйте 422.
Если проблема в том, что, как указано в вопросе, имя пользователя/электронная почта уже существует, вы можете использовать 409 Conflict [2] с описанием конфликта и подсказкой о том, как его исправить (в данном случае "выберите другое имя пользователя/адрес электронной почты" ). Однако в спецификации, как написано, 403 Forbidden [3] также может использоваться в этом случае, аргументы о HTTP-авторизации несмотря на это.
412 Условие не выполнено [4] используется, когда заголовок запроса предварительного условия (например, If-Match), который был предоставленный клиентом, оценивается как false. То есть клиент запросил что-то и предоставил предварительные условия, полностью зная, что эти предварительные условия могут потерпеть неудачу. 412 никогда не должны возникать на клиенте из синего и не должны быть связаны с объектом запроса как таковым.
Забавно возвращать 418 I'm a teapot запросы, которые явно создаются или вредны, и "не может произойти", например, сбой проверки CSRF или отсутствие свойств запроса.
2.3.2 418 Я чайник #/h3 >
Любая попытка кофе brew с чайником должна привести к ошибке код "418 Я чайник". Результирующий объект тела МОЖЕТ быть коротким и Толстый.
Чтобы он был достаточно серьезным, я ограничиваю использование смешных кодов ошибок конечными точками RESTful, которые напрямую не отображаются пользователю.