Какая архитектура подходит для веб-сервиса, который обслуживает и мобильное приложение, и браузер одновременно?

Как оптимально разделить разработку мобильного приложения (вероятно на Xamarin) и веб-сервиса для проекта, где функционал мобильного приложения не будет полностью дублировать браузерный клиент? Какую архитектуру использовать - смешанный подход MVC + WEB-API в одном проекте или разделение на микросервисы?

Также, насколько корректно взаимодействие мобильного приложения и веб-сервиса предполагать через обмен данными в JSON-формате посредством WEB-API?

Насколько необходимо применение токенов для авторизации вместо кукис, и следует ли использовать токен-авторизацию в рамках всего проекта или лучше применить ее только для мобильной части?
  • 9 декабря 2023 г. 12:37
Ответы на вопрос 4
Для веб-сервиса, который обслуживает и мобильное приложение, и браузер одновременно, рекомендуется использовать RESTful архитектуру. Это позволит создать отдельный API для мобильной части и веб-приложения, которые будут использовать общую логику сервиса.

Для оптимального разделения разработки мобильного приложения и веб-сервиса можно использовать подход MVC + WEB-API в одном проекте. MVC будет обрабатывать запросы от браузерного клиента, а WEB-API - запросы от мобильного приложения. Такой подход позволит эффективно использовать общий код и логику, но при этом избежать дублирования функционала.

Взаимодействие между мобильным приложением и веб-сервисом через обмен данными в JSON-формате посредством WEB-API является корректным и широко распространенным подходом. JSON является удобным и легким для обработки форматом данных.

Применение токенов для авторизации вместо кукис рекомендуется для обеспечения безопасности приложения. Токены в данном случае являются более современным и безопасным способом авторизации. Рекомендуется использовать токен-авторизацию как для мобильной части, так и для веб-сервиса. Это позволит упростить и обеспечить единообразие в процессе авторизации и аутентификации.
1. Сразу насчет микросервисов: оно, конечно, стильно-модно-модожежно, но для начала ознакомьтесь со свежим переводом недавней статьи на Хабре "Смерть от тысячи микросервисов" и задумайтесь: а у вас там точно требуется такой уровень гибкости, масштабирования и т.п., что без микросервисов никак. Задуматься стоит IMHO - выбор неоднозначный, и за вас его никто не сделает. 
2. Если вы знакомы с MVC и кго контроллерами, то вам будет несложно писать контролеры API на ASP.NET Core в старом добром стиле: традиционно они тоже базируются на инфраструктуре MVC. Там почти та же логика привязки параметров: ну, разве что, там стало автоматическим преобразование объектов на JSON из тела запроса в параметр-объект, но, вроде бы, можно использовать и старый стиль с несколькими параметрами с привязкой их одноименным свойствам объекта. Там используется та же самая маршрутизация по атрибутам - она должна быть вам знакома, если только вы не застряли в legacy времен MVC Framework 4, где была только центральная маршрутизация. Ну а возвращаемые объекты ASP.NET Core сам автоматически преобразует в JSON.
Правда, начиная с ASP.NET 6 появился (а начиная с ASP.NET 7 стал нормально документированым) альтернативный вариант создания API - Minimal API, но раз у вас есть опыт работы с MVC, то наверное, вам лучше остаться с этим старым добрым вариантом.
Насчет формата обмена - вызовов и результатов API - у вас полная свобода, но имейте в виду, что при использовании REST вы получите автоматизированню поддержку описания этих форматов через OpenAPI/Swagger: фронтовики с мобильщиками это оценят.
Делать ли генерацию HTML для браузера на веб-сервере через View по шаблонам Razor или же поручить эту работу фронтовикам, снабжая их данными через API - это предмет выбора, это зависит: как там у вас с квалификацией фронтовых разработчиков, как с требованиями к интерактивности страницы в браузере (MVC этому не способствует, костыли для подключения фронтовых фреймворков у MS, вроде как, есть, но я за них ничего не скажу - не пользовался), не придется ли по соображениям производительности переходить к Server Side Rendering (View - они как раз про это, а если изначально HTML генирился на фронте то перенести его в ASP.NET будет сложно) и т.п.
Авторизацация в ASP.NET Core есть из коробки, самых разных видов: часть уже встроена, для части придется подключать сторонние NuGet-пакеты, но подробности я вам тут не опишу.
А в общем совет у меня такой: собирайте информацию и думайте сами, а попытки копировать "как у других" - они могут привести к совершенно неожиданным результатам: каждая задача в чем-то уникальна.
Rest API 
Для авторизации можно как cookies, так и токен, особой разницы нет.
Похожие вопросы