помимо данных наподобие success: true? Никто с таким не сталкивался? Ведь для подобных проверок есть HTTP статусы
А если обновляешь сущность и у тебя она не обновилась, то что бэку возвращать? Какой статус? Запрос же по факту улетел и сработал. Просто обновление не произошло Ну это как я вижу, может я не прав
Если обновилась, значит 204 no content (как когда делаешь обновление через put/patch), если создать сущность то 201
Понял, спасибо Тогда у меня нет ответа на твой вопрос
Вам тоже спасибо, понял ход мыслей)
отправляю status true/false, проще хендлить в компонентах, чем гору из статусов
зато проще хендлить ошибочные состояния, обернул в try-catch и все
Если back-end обрабатывает все ошибки, возможно у них есть middleware для этого либо как сказали выше try/catch и отдается всегда успешный ответ, тогда по httpCode будет не понятно все ли хорошо. Но думаю на бэке так плохо делать
> httpCode будет не понятно все ли хорошо почему? там же статусов на любую ситуацию > Но думаю на бэке так плохо делать это же лучше чем всегда возвращать 200, не так ли? Либо я не понимаю до конца Вашу мысль
есть объединенное api для сайта и приложения на телефон, в каком месте понадобится http код
что это, какая-то библиотека? есть похожее на пример этого?
Моя мысль в том, что если на бэке обрабатывать все ошибки и всегда отдавать успешный ответ с полем success true/false - это плохо, лучше получать 200,201, 400, 401, 500 http-коды. Не понятно что происходить, возможно бэк будет присылать свой код ошибки (например 1, 2. 3, какой придумают + success false и клиент подключенный к апи должен завязываться на них, но я считаю если произошел сбой, например не удалось обновить сущность лучше вернуть ошибку(500) и внутри json с тем же кодом если нужно и текстом ошибки)
просто api сервис на nodejs
Обсуждают сегодня