Какой код ответа HTTP для «Это письмо уже зарегистрировано»?

Question

Я создаю RESTful API для создания пользователей, которые применяют уникальные адреса электронной почты:

Успешно POST /users: HTTP 201 Created

Если я POST снова получу тот же адрес электронной почты, каким должен быть код ответа? 409 Conflict соответствующий код ответа?

Answer 1

Да, 409 - наиболее подходящий здесь код ответа.Даже если вы, скорее всего, вернете значение 201 в случае успеха, вы все равно будете отправлять POST-сообщение на ресурс, который описывается как коллекция, а POST-сообщение дублирующегося электронного письма определенно конфликтует с «текущим состоянием ресурса» в качестве коллекции.Вам следует вернуть тело ответа с описанием проблемы и гиперссылками, чтобы помочь решить проблему, если это возможно.

Answer 2

Я не очень доволен возвращением 409 Conflict для существующего зарегистрированного электронного письма - на мой взгляд, это не ошибка клиента.Итак, давайте посмотрим, как некоторые крупные технологические компании справляются с этим делом (по крайней мере, как они делают это в своих API-интерфейсах веб-сайтов).* и объект JSON, содержащий код, который указывает, что электронная почта уже зарегистрирована.

Facebook также возвращает 200 OK, но повторно отображает содержимое на странице восстановления, чтобы дать пользователю возможность восстановить свою существующую учетную запись.

Twitter проверяет существующую электронную почту с помощью вызова AJAX на другой ресурс.Ответ ресурса проверки электронной почты всегда равен 200 OK.Ответ содержит объект JSON, содержащий флаг, чтобы указать, зарегистрирован ли адрес электронной почты или нет.

Amazon делает это так же, как Facebook.Возврат 200 OK и повторное отображение содержимого на странице уведомлений, чтобы проинформировать пользователя о том, что учетная запись уже существует, и предоставить ему / ей возможность предпринять дальнейшие действия, такие как изменение логина или пароля.

Таким образом, все эти API-интерфейсы всегда возвращают 200 OK и представляют клиенту / пользователю либо дополнительный контент для восстановления своей учетной записи, либо сообщение об ошибке, которое возникает в теле содержимого ответа.

Answer 3

Хотя принятый ответ верен и показывает правильный код состояния для задачи, я хочу добавить, что вы вводите уязвимость безопасности.

Если вы возвращаете 409 для регистрации учетной записи, вы просто выставляетеслужба для перечисления учетной записи.

Зависит от приложения, если API общедоступен или нет, и т. д., вы можете вернуть 201, даже если учетная запись не была создана.

Answer 4

+ 1 к ответу Барта - по соображениям безопасности. Обычно я согласен с тем, что 409 - это хороший код состояния для sth. это уже существует. Но в среде учетных записей пользователей / аутентификации / авторизации и т. Д. Я бы не стал выставлять существующие учетные записи пользователей в вашей базе данных.

Конечно, в этом месте есть и другие механизмы обеспечения безопасности. Если вы не против выставить небольшое количество своих учетных записей, вы можете добавить в свое приложение поведение, которое возвращает 401 или 403 для многочисленных событий 409 с одного IP.

Другой вариант (в общем) - определить код состояния самостоятельно, чтобы иметь 2xx, который отличается от существующих стандартных вариантов 2xx. Это может быть вариант, если вы не хотите обрабатывать «уже существует» как ошибку. Однако это будет считаться нестандартным и иметь такой же небезопасный символ, как 409 в вашем конкретном примере.

Answer 5

Я часто использую (расширение WebDAV) HTTP 422 Необработанный объект :

Запрос был правильно сформирован, но его не удалось выполнить из-за семантических ошибок