и сервера через http json. Его аргументы: rest гавно, нужно все через post отправлять, а коды ошибок 200 возвращать, если ошибки на уровне транспортного протокола.
Я думаю, что лучше использовать get, post, put, del (смог убедить).
Но что с возвратом кода ошибок в head request? Вы возвращаете что-то отличное от 201 или 200, если в бизнес логике на серваке произошла ошибка?
Н.р. нет поля, я это обработал и не свалилися, какой код вернуть?
Я думаю, что это странно заменять код ошибки на текстовый код, если есть HTTP эквивалент, например 401 и 429. Как мимимум это удобнее логировать и обрабатывать.
Нужно в success колбеке обрабатывать еще и ошибки. Кто-то так делает?
т.е. если я запрашиваю не существующего пользователя, обратно бек отдаст 200 и пустой массив или пустоту.
Или если я не прислал одно важное поле, то вернет 200 и код ошибке в теле ответа.
ох вам спорить и спорить ещё..)
Бек дело говорит. Рест который привязывается к методам http и кодам его ошибок действительно не лучшее решение. Что делать если потребуется еще типы экшенов кроме get, post, put, del (напрмер restore) ? А если нужно добавить еще один тип ошибок - искать в спецификации по http код ошибки чтобы все было по ресту? А если нет кода специфичного для этого типа ошибки? А если вдруг захочется сделать общение с сервером не через http а по вебсокетам? В вебсокетах уже нет никаких методов вроде get post put и т.д и нет кодов ошибок - там можно передавать любые json-объекты. Можно конечно эмулировать рест методы и коды ошибок реста в json-объектах но зачем изначально завязываться на http? Не проще ли определить удобный приложению транспортный протокол передавая в json-объектах какую-угодно схему запросов и ответов с которой удобно работать (и не нужно будет переписывать когда изменится транспорт) а http (как и вебсокеты) использовать просто как транспортный уровень передавая json-объекты в post-запросе и не париться. Кстати graphql тоже передает все запросы через post.
Обсуждают сегодня