Comments 4
Если сервер не может отработать запрос по причине какой то продуктовой логики, следует ли отвечать с http 5xx кодом (и на клиенте ловить ошибки в try catch) или изначально оставить http коды только для транспортных ошибок, а проблемы с логикой оборачивать в свою логику при которой все ответы будут обернуты дополнительным полем со статусом типа {"status":"ok", "response": data}?
{"status":"error", "description": "баланс тютю"}?
Я не вижу ничего плохого в том, чтобы активно использовать различные HTTP статусы и связывать их с бизнес логикой приложения. Если вы делаете REST API, такой подход будет более логичным. Но и описанный вами вариант, где при продуктовых ошибках статус ответа всегда 200, тоже имеет право на жизнь, многие его найдут даже более удобным. Поэтому советую вам выбрать тот формат, который больше всего вам нравится, но не забудьте хорошо задокументировать свой выбор, чтобы у пользователей API было меньше сложностей
Если это не публичное API, то пусть решает пользователь API, например, фронтэнд. Как им легче обрабатывать ошибки.
Работаем с HTTP API: разбор частых проблем и методы их решения