REST + API + Response

[@Дмитрийсекрет-н7о]

Спасибо. Интересный урок по API

[@SergeiCalabonga]

Всегда пожалуйста!

[@salov_ev]

Прикольный подход :) я обычно просто респонс объект возвращаю но тут круто что можно вернуть разные значения и к тому же минимум кода и модификаций

[@SergeiCalabonga]

Мне тоже очень нравится. А ещё это соответствует Single Responsibility Principle (SRP). И это практика из большого опыта.

[@СергейДовгалев-ц1щ]

Интересный подход! Спасибо. И повеселили, ошибка 401, 400, 500, 0, какой 0?! Соврал)))

[@SergeiCalabonga]

Программировать надо весело!

[@АртемАмангалиев-т7у]

Здравствуйте, может быть расскажите в видео про ConfigureAwait()?

[@SergeiCalabonga]

Кажется "изжёванная" тема. Куча информации в интернете.

[@НатаниэльДампо]

Не понимаю, почему не сделать отлов exception с переводом его в коды ответов , один раз сделали и везде используем не извращаясь над бизнес логикой. Да exception нельзя использовать вываливая исключения как постоянные ответы , но ведь это исключения на нештатные ситуации которых не должно быть. Если разраб бомбит api невалидными данными, то надо решать кривизну его рук)

[@SergeiCalabonga]

Делай как нравится, я тоже так делаю. Я же не заставляю делать как я. Я просто поделился опытом. Сделай видео о своём опыте - посмотришь комментарии о нем, всё сразу станет на место. 😁

[@arfreekiller]

@@SergeiCalabonga а если без холиваров, то чем плох такой подход?

[@МихаилСкляренко-б4с]

При таком подходе, каждый раз, при выбросе исключения будет собираться стектрейс, что довольно накладно и будет замедлять работу приложения (критично для хайлоад)

[@SergeiCalabonga]

@@МихаилСкляренко-б4с дык, не выбрасывать тогда! Класс исключения показан только в качестве демонстрации. Создай свой класс DTO и выкидывай его. Забудьте вы уже прл исключения, видео не об этом.

[@andrey_aka_skif]

Как я понял, автор делает упор на способ правильно вернуть результат из контроллера. Т.е. вместо IEnumerable он возвращает IActionResult. По идее, можно вернуть ActionResult. Но суть та же. Это не голые данные, а контейнер, который содержит и данные и дополнительную информацию. Например, описание ошибки. Однако, чтобы не засорять контроллеры бизнесовой логикой, он вынес её в сервис. И для удобства возвращает Operation.Result. Как я понимаю, у Вас возникли вопросы именно к этому? В таком подходе фактически используется паттерн Result. Он ещё напоминает монаду (но не готов обсуждать подробнее). Идея в том, что Exception это исключительная ситуация, с которой хз что делать. Обычно "ошибка" сервиса вполне осмысленная, а то и вовсе не ошибка. Например, 409 Conflict никакая не исключительная ситуация. Абсолютно рядовая ситуация при дублировании имени пользователя. Зачем нам падать? Можно вернуть объект, содержащий или данные или сообщение с подробностями. Т.е. работая с сервисом, который возвращает Result, мы уверены, что в нем не возникнет Exception. И нам не нужно дополнительно оборачивать его в try/catch. При этом в самом сервисе try/catch очень даже могут быть. Но свои ошибки сервис отлавливает сам. А контроллер его спокойно пользуется.