ошибка сервера, так как он пытается на основе данных токена обновить пароль меняя запись пользователя в БД, но не может так как данные запроса не валидны. Или лучше использовать тогда статус Bad request( номера кода я счас просто не помню ) ?

чем плохая? довольно частая практика, потому что фронт уже сам может решать какие текстовки и как обрабатывать такие ситуации, не опираясь на реализацию бэка, например есть два фронта и 1 сторонний сервис которые пользуются апи твоего бэка и у всех у них разное поведение в твоей ситуации, у одного одна текстовка, у другого другая, а у сервиса вообще текстовки никакие не нужны и намного удобнее по коду определить, что случилось

Как по мне это 403

1. В тексте ошибки не писать, что токен принадлежит другому пользователю (Это раскрытие реализации для тех, кто потом будет ломать апи).
2. Просто вернуть 403 если токен не совпадает с пользователем или 404 если не найден. А если нужен бизнес-текст "Wrong token" в обоих кейсах.
3. На фронте лучше разруливать поведение по статус кодам, а не по тексту ошибки.

по двум причинам плохая:
1. если не давать никакого намёка с сервера почему твой запрос провален, то на фронте нужно написать больше лишнего кода и хранить сообщения об ошибке на нём.
2. нужно адаптировать api приложения, чтобы им было удобно пользоваться не только через UI в странице браузера, но и другие http клиенты, как, например, через тот же curl. UI - это инструмент для обращения к api, но фронт не должен черезчур принимать на себя ответственность за его работу.

Намёк есть - внутренний код ошибки, например wrong_token, http клиентам как раз удобнее коды обрабатывать чем Длинный непонятный текст

Если тебе скажут текстовку поменять, то ты на всех своих клиентах будешь обработку менять?

да. Та ошибка пароля - самая расспространённая ошибка, которая коснётся одинакого всех юзеров. Поэтому я не вижу смысла разбивать его логику во фронте

Клиенты это не юзеры, а сервисы...

ааа тогда нет. Но это не мало лишнего кода во фронте

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

вот и причина, почему я так с этими эксепшенами заморачиваюсь

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

Не мало? Просто мапа с кодами ошибок и их описанием

спасибо за ответ. Я конечно подумаю, но на будущее, так как обработка ошибок зависит ещё и от того, на какие он http клиенты кроме браузера расчитан. Ведь я иногда использую и swagger. Хоть он и браузерный, но он тоже должен возвращать понятный ответ

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

p.s. в случае ошибки на сервере будет возвращено 400, типо, что запрос кривой

зачем 403 ?? Чем он логичнее моего статуса ??

400 bad request - чаще используется при неправильном формате запроса, отсутствующих обязательных параметрах, ошибках синтаксиса

Тем и логичнее, что 403 forbidden - запрет на доступ к ресурсу. В твоем случае объекту пользователя, у которого сбрасывается пароль.