REST + API + Response
HTML-код
- Опубликовано: 30 мар 2024
- Благодарности и помощь каналу принимаются:
www.calabonga.net/site/thanks
Наши видео доступны и на Дзэн:
dzen.ru/calabonga
Можно стать спонсором, и вы получите доступ к эксклюзивным бонусам:
* boosty.to/calabonga
Я использую хостинг Reg.ru
htttps://reg.ru/?rlink=reflink-11163551
Спасибо. Интересный урок по API
Всегда пожалуйста!
Прикольный подход :) я обычно просто респонс объект возвращаю но тут круто что можно вернуть разные значения и к тому же минимум кода и модификаций
Мне тоже очень нравится. А ещё это соответствует Single Responsibility Principle (SRP). И это практика из большого опыта.
Интересный подход! Спасибо. И повеселили, ошибка 401, 400, 500, 0, какой 0?! Соврал)))
Программировать надо весело!
Здравствуйте, может быть расскажите в видео про ConfigureAwait()?
Кажется "изжёванная" тема. Куча информации в интернете.
Не понимаю, почему не сделать отлов exception с переводом его в коды ответов , один раз сделали и везде используем не извращаясь над бизнес логикой. Да exception нельзя использовать вываливая исключения как постоянные ответы , но ведь это исключения на нештатные ситуации которых не должно быть. Если разраб бомбит api невалидными данными, то надо решать кривизну его рук)
Делай как нравится, я тоже так делаю. Я же не заставляю делать как я. Я просто поделился опытом. Сделай видео о своём опыте - посмотришь комментарии о нем, всё сразу станет на место. 😁
@@SergeiCalabonga а если без холиваров, то чем плох такой подход?
При таком подходе, каждый раз, при выбросе исключения будет собираться стектрейс, что довольно накладно и будет замедлять работу приложения (критично для хайлоад)
@@user-im6lx5yb7e дык, не выбрасывать тогда! Класс исключения показан только в качестве демонстрации. Создай свой класс DTO и выкидывай его. Забудьте вы уже прл исключения, видео не об этом.
Как я понял, автор делает упор на способ правильно вернуть результат из контроллера. Т.е. вместо IEnumerable он возвращает IActionResult. По идее, можно вернуть ActionResult. Но суть та же. Это не голые данные, а контейнер, который содержит и данные и дополнительную информацию. Например, описание ошибки.
Однако, чтобы не засорять контроллеры бизнесовой логикой, он вынес её в сервис. И для удобства возвращает Operation.Result. Как я понимаю, у Вас возникли вопросы именно к этому? В таком подходе фактически используется паттерн Result. Он ещё напоминает монаду (но не готов обсуждать подробнее). Идея в том, что Exception это исключительная ситуация, с которой хз что делать. Обычно "ошибка" сервиса вполне осмысленная, а то и вовсе не ошибка. Например, 409 Conflict никакая не исключительная ситуация. Абсолютно рядовая ситуация при дублировании имени пользователя. Зачем нам падать? Можно вернуть объект, содержащий или данные или сообщение с подробностями. Т.е. работая с сервисом, который возвращает Result, мы уверены, что в нем не возникнет Exception. И нам не нужно дополнительно оборачивать его в try/catch. При этом в самом сервисе try/catch очень даже могут быть. Но свои ошибки сервис отлавливает сам. А контроллер его спокойно пользуется.