начинается расслоение бизнес логики многих "атомарных" операций на сервер и клиент., т.к. вы не можете выполнить все на клиенте, и вы будете вынуждены разрывать многие "единые операции с точки зрния логики" на 2 части - клиент и сервер. просто потому, что вы не имеете права отгрузить клиенту некоторые данные в силу требований безопасности
============================
жизненный цикл приложений построенных на рест стремится к обработке данных на клиенте. сам по скбе рест сервис этому способствует. это передача данных клиенту, обработка данных на клиенте тяжелым js, передача данных на сервер. на этот цикл у вас завязано 99% всех актуальных js-фреймворков. посмотрите например на ту же компоненту типа handsonTable - она не держит на клиенте только "отображение". вы сгружаете клиенту полный объем данных, он их жует-редактирует и потом вы всю пачку пытаетесь отослать на сервер и там прожевать.
хотя это можно пытаться нивелировать разарботкой на typescript с последующей трансляцией в js, но typescript далеко не самая распространенная технология
но что вы будете делать на сервере, когда вам по сценарию надо будет в определенной точке алгоритма отослать ответ, а потом ждать очередной запрос от клиента, что бы ответить ему используя ранее полученные данные ?
и организационных ( каждое подключение надо идентифицировать и авторизовать, и передать пакет туда куда нужно - там где ждут ответный пакет от клиента, или тнадо найти серверный объект который хранит состояние клиента сейчас ) - т.е. у вас банально уходят ресурсы на восстановление контекста или сессии в котором надо выполнить этот запрос. это и на сервере и на клиенте.
[Authorize(Roles = "admin,manager")]
JsonResult MyMethod() {
}
но вот нет хороших промышленных решений работающих по этим принципам. есть c++/qt и их трансляция формы в веб. есть java и jsf, в варианте какого нибудь там primefaces, вроде как есть vaadin, но как я понимаю, это фактически перекомпиляция java в js с полной отгрузкой приложения клиенту (что малопригодно в ситуации недоверия клиенту).
СЭД (системы документооборота), арм различных госструктур, арм различных операторов, и тд.
90% последователей этих технологий не понимают даже основ проблем разработки больших систем на языках с динамической типизацией
одна только попытка использовать stateless подход и тяжелый толстожЁпый js грозит вам переработками такого масштаба
я вижу перспективу в использовании web-socket, но опять же, промышленных наработок и фреймворков нет.
В контексте вопроса - дотнет кор тоже не решает вопросы связанные с тем "как писать веб-приложения как будто для тдесктопа". Или решает?
Что они предлагают для того что бы не городить "частокол костылей rest-сервисов" ?
void btn_Click(Object sender, EventArgs e) { }
Но даже в этом случает предварительно пришлите ссылку на алгоритм заказчику, чтобы он подтвердил, что это то самое.
Придумывать алгоритм расчета - не работа программиста.