Код приложения ничего не сможет сделать с этой ошибкой, эта ошибка – для разработчика.

Если какой-то required параметр не передан – всё, клиентская часть (фронт) работать не может, это фатальная ошибка. Назад вызывающему нельзя возвращать ничего кроме ошибки, потому что мы так и не поняли, был там юзер в базе, или нет.

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

Но вообще говоря, в обычных условиях эти ошибки фатальны, и просто должны писаться в лог для отладки.

Во, хороший ответ: «Если ошибка не фатальная, а является ответом на запрос – то статус всё равно 200, а если ошибка не позволяет запросу корректно отработать – то статус нужно вернуть другой».

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

Да и все равно ты теперь бизнес ошибки объявляешь через ошибки транспортного уровня.

Тогда уж лучше обычный рест

> Второе - штатная ситуация, а никак не исключение

Во-от!

Хотя, отсуствие пользователя может и быть нештатной ситуацией в некоторых алгоритмах, например – отсуствие «текущего» пользователя, из-под которого работает фронт. Тогда это скорее всего будет exception, и продолжать всё равно нельзя.

Но с точни зрения логики самого API – это как раз нормальный отрицательный ответ. Как «неверный пароль» – неверный пароль не должен отдавать 403, потому что 403 – это когда вы не имеете права даже пытаться вводить какой-то там пароль!

Это не так, 403 подходит для неверного пароля

function remove_file(name){
 if(!name || typeof name !== 'string')
   throw new Error('Wrong call');
 // далее – вернуть true если файл удалён или не существовал, и false если удалить не получилось
}

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

И это не должно случаться в реальной программе, ни при каких условиях!

Это разные типы ошибок.

А когда пользователь не имеет прав на вход (забанен) – то что, «403*», четыреста три со звёздочкой?

If authentication credentials were provided in the request, the server considers them insufficient to grant access.

Как я и сказал

Валидация входящих параметров - это бизнес операция, она не может быть фатальна

Подскажите как лучше всего реализовать авторизацию пользователя, чтоб было меньше рисков авторизоваться за счёт краденого куки? Я смотрел jwt, но там передают обычно username и _id, это же тоже не безопасно.

Сессия

передавать в jwt id сессии?

Нет, юзать сессию без jwt

Просто 403

Спасибо

А как у тебя куку украдут?

через xss

Использовать csrf токен

Или http only на куку