Google 有一个演示来演示您所指的这种方法。这是 Google App Engine 的 Autoshoppe Demo。尽管它是 Java，但这些概念也适用于 .NET 应用程序。
该应用程序包含带有 .html 扩展名的普通 HTML 页面。没有服务器端视图技术使 HTML 程序员的生活复杂化。 HTML 页面使用 JavaScript AJAX 与使用 Spring 3.0 构建的 REST Web 服务交互，后者与数据存储交互。
- 请求数据在请求中作为 JSON 传递
- 响应数据在响应中以 JSON 格式返回。
这意味着任何人都可以在此 API 之上构建用户界面，或者您可以创建一个与该数据交互的 .NET 项目。 REST 是一种出色的架构，可用于创建可扩展的分层服务。
我认为这种技术没有被广泛使用的原因是因为许多人坚持使用鼓励开发人员在 HTML 中使用视图技术供应商的标记的视图技术，例如 ASP 文件（或用于 Java 的 JSP）。这种做法已经存在了一段时间，因为这些框架的作者基本上是工程师，而不是网页设计师和 UI 设计师。
还需要对 REST 有相当深入的了解才能看到这种方法提供的优势，而初级开发人员有时会在这些概念上遇到困难。
如果您要在 .NET 中解决这个问题，使用 AutoShoppe 演示作为指导，您很可能希望使用可以将 JSON 转换为 .NET 对象并返回 JSON 的对象映射器。这比尝试自己解析 JSON 更简洁。
这种 RESTful 方法的优势在于，您的内容、行为和表示是完全 100% 独立的，您可以为您的网络程序员提供 HTML 文件，而他/她可以完全在 .NET 之外运行它们环境。然后，您的设计人员可以使用他们的工具并专注于他们的优势，而无需安装、配置或运行 Visual Studio.NET。事实上，这些文件可以直接从桌面运行。
编辑：也许一个缺点是在许多 MVC 框架中对此没有太多支持，主要是因为它是一个新概念。客户端和服务器端之间的桥梁目前必须由开发人员编写。
在 AutoShoppe 演示中，开发人员用 JavaScript 编写了一个原型类来处理在发送到服务器之前将数据转换为 JSON，他们必须编写 JavaScript 代码来将 JSON 编组为 JavaScript 对象并将该数据操作回 HTML。在服务器端，他们确实使用对象映射器将 JSON 反序列化为对象。大部分复杂性都在服务器上。
将服务器端组件转变为 100% 可重用的 RESTful 服务，设计人员和客户可以轻松地与之交互，其优点可能会超过缺点，具体取决于场景。一个很好的例子可能是鼓励您的客户编写自己的用户界面或完全控制产品白标的服务。这是why I won't use server side view technologies 的众多原因之一。