Какой статус код использовать при регистрации если почта занята?

Question

[historydev]

Допустим на плохой запрос 400, если всё ок - 200, не авторизован 401, а какой использовать в моём случае?

Comments

[Lynn «Кофеман»]

Ну если зачем-то хотеть HTTP код, то на мой взгляд 409 Conflict.

Но на самом деле это какая-то глупость. Куда и зачем вы собираетесь отвечать такой ошибкой?

[historydev]

Lynn «Кофеман», я просто ставлю статус ответу и отправляю сообщение с подробностями или данными в зависимости от статуса, а на фронте обрабатываю статус и в зависимости от него вывожу что-то, это ведь api.

[historydev]

Lynn «Кофеман», conflict это состояние на сервере, что в моём понимании запрос был отправлен повторно до окончания обработки предыдущего

[Lynn «Кофеман»]

Владимир, ну извиняйте, никто в HTTP не придумывал семантику «логин уже существует».

Но вообще в описании 409 нет ничего про «повторный запрос».
Это просто «запрос не может быть выполнен т.к. противоречит текущему состоянию системы». Под это вполне можно притянуть конфликт с уже существующим логином поскольку использование HTTP-кодов (кроме самых тривиальных) в API это практически всегда натягивание совы на глобус.

Answer 1

[Василий Банников]

Лучше вообще никакую ошибку не сообщать, ибо это потенциальная дыра в безопасности.
Злоумышленник таким образом может через тебя прогнать свою базу адресов и узнать, какие люди у тебя зарегистрированы, что может быть нежелательно.

Лучше продолжай регистрацию как обычно и отправляй на почту сообщение типа

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

Comments

[historydev]

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

[Василий Банников]

Владимир,

Везде же пишут что почта там или телефон занят, или аккаунт такой есть

Нет, не везде. Советую обратить внимание на какие-нибудь крупные сервисы, которые работают с чувствительной инфой.

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

А ты просто пиши, что чтобы продолжить регистрацию - перейдите по ссылке в письме.

Ну или просто разрешай продолжить регистрацию, но проси код подтверждения из смс или email - считай что чел так просто восстанавливливает пароль (в случае email, тогда можно и данные сохранить) или регистрируется совсем с нуля (в случае телефона, ибо номер может переходить от одного человека к другому. В таком случае замораживай как-нибудь старый аккаунт)

[historydev]

Василий Банников, да, вы правы, учту, спасибо!

[WbICHA]

Василий Банников, по факту это актуально только для чего-то серьёзного. А чтобы через регистрацию не прогнали базу адресов, можно добавить проверку на робота.

[Василий Банников]

WbICHA, реализуется это достаточно легко, а то, что кажется вам не серьёзным - для конечного пользователя может быть наоборот очень серьёзным.

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

А иногда может быть наоборот - 1 адрес и база сайтов.

[WbICHA]

Василий Банников, юзеру всё равно как легко или просто это реализуется в коде, ему вамжно в первую очередб удобство. Во всяком случае 99.99% пользователей. И сразу бежать на почту при регистрации это не самая удобная процедура.
Оставшиеся 0.01% "серьёзных пользователей" всегда могут воспользоваться одноразовым эмайлом или, что скорее всего, будут иметь отдельный мусорный майл для таких сайтов (а это почти все).

Так что то, о чём ты говоришь, в реальности актуально только там, где нужна повышенная безопасность.

Answer 2

[Владимир Коротенко]

https://developer.mozilla.org/en-US/docs/Web/HTTP/...

так что можно выбрать подходящий например 404 как одна страна в европе

Comments

[historydev]

но ведь 404 это не найден, в таком случае при регистрации я могу отвечать не 200, а 404?

[historydev]

Если буквально воспринимать то, что там написано

[Владимир Коротенко]

Владимир, выберите из этой таблицы
https://yandex.ru/support/webmaster/error-dictiona...
409, 412, 422, 423, 424
Выбирайте любой заголовок подходящий по вашему мнению.
можете даже 200 выбрать и проверять ответ на клиенте что то типа такого в ответе

{
status: 200,
body:{ ab: 1}
}
или 
{
status: 409,
error: "duplicate email"
}

[historydev]

Владимир Коротенко, я уже проверяю вот так:

switch (res.status) {
					case 200: return res.json();
					case 451: return (async () => {
						const data = await res.json();
						if(data.field === 'email') form.controls['email'].setErrors({'email_busy': true});
						return data;
					})();
					default: return res.status;
				}

В моём понимании статус должен отражать суть операции, хочу писать хорошее api

[Владимир Коротенко]

Владимир, хорошее api это то которое сообщает об состоянии статус из 3 цифр не говорит ни о чем.
вот вы сами спрашиваете какой код отправить

сделайте так :
200

{
  error: "Email already exist",
  tip: "Use another email, or login with [e-mail]" 
}

и проверяйте на клиенте есть ли поле error

[historydev]

Владимир Коротенко, Как понять в какой ситуации нужно юзать определённый код, а в какой нет? Допустим basic auth отвечаем 401 если не прошёл

[WbICHA]

Владимир, очень просто, если ты используешь подход "всегда 200", то сервер должен всегда отвечать с кодом 200, а по ответу уже смотреть есть там ошибки или нет. А если ты используешь подход "статус код фапер", то, следовательно, всегда указывай наиболее актуальный код.
Но у "всегда 200" есть одна особенность: в консоле браузера будет трудно отслеживать бизнес ошибки по статус коду, зато прочие ошибки (любой не 200) будут видны сразу.