我正在构建一个客户端脚本很重的ASP.NET MVC应用程序，它将使用JSON和jQuery来操作DOM。
我的理解是 Web API控制器和 MVC控制器都可以返回JSON。
根据我的情况，我应该使用 Web API控制器还是 MVC控制器？
答案 0 :(得分：155)
可以在任何ASP.NET应用程序中创建和托管Web API控制器，而不仅仅是MVC应用程序。因此，创建Web API的一个明显原因是，如果您没有MVC前端（例如，由您的公司/组织托管的经典，RESTful Web服务。）
MVC控制器通常依赖于MVC框架，如果你查看默认模板以及社区和同行完成的大部分工作，你会注意到几乎所有的MVC控制器都是以View为目的实现的。
就个人而言，当我打算使用View（）进行响应时，我会使用MVC控制器，并且我会将Web API用于任何不依赖于特定视图的内容。
当然有一些警告，但一般来说，如果你不需要MVC的模型绑定行为，你的服务是以数据为中心的，而操作是以数据为中心的（例如CRUD操作），那么你可能想要一个' Web API Controller'而不是'Model-View Controller'。相反，如果您的操作是以视图为中心的（例如向用户提供用户管理页面），或者您需要MVC的模型绑定来生成'ajax partials'（非常不可能），那么您将需要一个MVC控制器。
就个人而言，我使用Web API控制器来驱动基于JSON的RESTful客户端，我使用MVC控制器来处理基本的浏览器路由和SPA的交付。
答案 1 :(得分：30)
WebAPI用于制作API。如果您希望某人能够以XML，JSON等方式使用您的API，您可以制作一个Web api。
在您的情况下，您只需要使用JSON与客户交谈。
即使您的网站主要是客户端脚本驱动，您仍然会使用ASP.NET MVC Controller吗？既然你可能已经基于实体对控制器进行逻辑划分，那么在其中添加这些json服务方法是有意义的，而不是专门为web api创建另一个类。
因此，对于您的特定情况（如果我理解正确的话），我会坚持使用控制器。
答案 2 :(得分：7)
答案归结为分离关注点，加强服务的创建以及依赖惯例而不是配置。
控制器的主要职责是作为视图和模型之间的协调者，但API的主要职责是处理数据。在API的约定的情况下，使执行CRUD操作变得非常容易。下面是CRUD操作和HTTP操作之间的映射
因此，使用API，您不必创建单独的操作，并使用HTTP操作对其进行归属。
答案 3 :(得分：0)
我对ApiController的唯一顾虑是它是基于站点而不是基于区域的。 一个站点只能有一个apicontroller子文件夹供您命名控制器方法。 在某些情况下，您可能希望在不同区域复制控制器名称：
domain.com/api/area1/controller1 /
domain.com/api/area2/controller1 /
我记得有一些自定义代码设置可以执行此操作但默认情况下不起作用。
答案 4 :(得分：0)
我同意Shaun Wilson的回答，但不确定为什么我只是有点困惑，仍然试图理解以下（可能是不正确的）预感 -
你知道，我只是不知道我在这里是不正确的并且感到困惑，因为Shaun的最后一行回答说“我使用MVC控制器来处理基本的浏览器路由和SPA的交付。” - 当我假设它可能是以JSON形式接收响应的JavaScript方法时，我可能还不完全知道什么是一个宁静的客户端。这是Stackoverflow中最接近的帖子，它作为我的问题的答案远程相关，所以我回答这篇文章，而不是可能重复问题。
答案 5 :(得分：0)
在这种情况下，我建议使用WebApi，因为它非常适合根据Javascript请求传输此类数据。我通常会开发我的WebApi控制器，以便它们返回一个JSON友好对象，然后可以通过我的Javascript轻松解析。
如果您想要生成一些HTML并使用Javascript调用替换页面片段，那么您希望在MVC控制器上使用某个操作的唯一实时情况就是。
例如：
您有一个JQuery UI Datepicker，在选择时会生成一个单选按钮列表，用于表示所选日期的事件。
在这种情况下，您可以使用WebApi返回一些JSON，然后使用Javascript生成必要的HTML，但通常使用Javascript创建大量HTML是不好的做法。让C＃构建HTML然后通过部分视图返回它会好得多，因为这样你不太可能遇到Javascript解析错误。更不用说它使HTML更容易编写。