在同一解决方案中从 MVC 应用程序调用 Web API答案

【问题标题】：Calling Web API from MVC Application when both in same Solution在同一解决方案中从 MVC 应用程序调用 Web API
【发布时间】：2014-02-16 20:18:20
【问题描述】：

所以我对 Web API 完全陌生，我想我会开始一个测试项目来学习它和 AngularJS 以及它们如何很好地协同工作......等等。

我在我的解决方案中创建了一个多层架构，在我的TPlan.API 项目中，我在Global.asax 中配置了以下路由

GlobalConfiguration.Configuration.Routes.Add("default",
            new HttpRoute("api/{controller}"));

TPlan.WEB 是我的 MVC 应用程序，它被设置为“启动项目”。当我运行它时，我希望能够去：

mysite:port/api/test

然后从我的测试控制器那里的 API 中获取值。

但是它对我不起作用，我得到以下信息：

未找到与请求 URI 'mysite:port/api/test' 匹配的 HTTP 资源。

【问题讨论】：

标签： asp.net-mvc asp.net-web-api

【解决方案1】：

呃，在 Visual Studio 中，右键单击解决方案并转到属性。转到启动并选择“多个项目”选项并勾选网站和网络服务以同时启动。

这将启动他们两个。但正如已经指出的那样，它们在不同的端口上运行，它们是完全独立的应用程序...... 我认为您不能注册属于网站之外的路线。

我们是这样工作的

查看 => POST / GET => MVC 控制器 => HTTP 请求 => API 控制器

所以我们的 mvc 视图发布或访问我们的 mvc 控制器，然后我们向 web api 发出单独的 http 请求。这是一个服务器到服务器的调用，就像调用任何外部 Web 服务一样。我们等待来自 api 的响应，然后返回视图所需的任何内容...

【讨论】：

感谢您的掘金。
说得好。顺便说一句，您只需右键单击 Web API 项目并选择 Debug > Start，然后对 MVC 项目执行相同操作。

【解决方案2】：

如果不提前将 WebAPI 项目安装到 IIS 中，您所尝试的操作在逻辑上是不可能的，我敢肯定这不是您想要的。两个项目不能同时运行，因为只有一个项目能够启动 IIS Express 的调试会话。即使两个项目能够同时运行，它们也将位于不同的逻辑端口上，并且必须将来自一个项目的路由手动发送到另一个实例的侦听端口。基本上，您的 API 项目上的 Global.asax 将永远不会运行，因为该项目将构建为类库。

【讨论】：

嗯，那么构建 AJAX 繁重应用程序的人如何进行测试呢？我希望让 AngularJS 调用数据并从我的 Web API 中获取 JSON，但都在同一个解决方案中。 ://
在我见过的每个项目中，WebAPI 都在 Web 项目中，而不是单独的类库中。如果您的项目主要是 Angular.js，那么 WebAPI 和 MVC 会发生冲突的其他 MVC 页面不应该足够多。
我明白了。所以如果我将我的 Web API 移动到 Web MVC 项目中，那可以正常工作吗？而且我的 API 可以提供其他人的数据以供消费？
另外，如何将 API 逻辑从主 MVC 应用程序中分离出来？我会创建一个单独的区域来容纳所有 API 相关的类吗？
您当然可以拥有一个单独的类库，所有 API 控制器都从中调用函数，但实际的控制器和路由逻辑仍然存在于 MVC 项目中

【解决方案3】：

使您的 TPlan.API 项目成为一个简单的程序集，从 TPlan.Web 引用它并将 GlobalConfiguration.Configuration 属性传递给您的 API 程序集中的注册方法。当 MVC 项目启动时，MVC 路由和 Web Api 路由都将在同一个 Web 主机上处于活动状态。

Here 是在同一解决方案中同时具有控制台主机和 Web 主机的 API 示例。

【讨论】：

这会使您的无状态 RESTful API 倒退到旧 Web 服务的思维模式中。 Web API 的魅力之一是您的 UI 不必引用程序集。尽管旧的 SOAP 或 ASMX Web 服务具有服务引用是正确的，但将这种思维方式带入 Web API 几乎感觉就像打破了关注点分离。当然，这可能只是调试的一种解决方法，并且在生产中两者是分开的，因此是一种良好的实践。但这几乎似乎助长了一个可能的坏习惯。
@Suamere 将 HTTP Web API 构建为 MVC 站点的服务接口几乎总是浪费时间、精力和性能。
这是一个强有力的声明。根据我自己的经验，我没有看到浪费。我以前从未听说过，而且自从你说之后，我还没有找到支持该声明的信息。可以提供一些详细说明的讨论的链接吗？我理解的方式是：您应该在 api 子域上有一个不同的 Web API 项目，或者如果它保留在您的 MVC 站点中，则应该在项目的自己的子文件夹中完全隔离，而不是与 MVC 混合。两种方式应该具有相同的性能，并且似乎更容易维护单独的层。
@Suamere 等到第三方依赖于您的 API，然后看看当您尝试更新您的 MVC 站点并破坏该第三方时会遇到多大的痛苦。

【解决方案4】：

请检查以下网站。我认为问题在于路线的配置

http://www.asp.net/web-api/overview/extensibility/configuring-aspnet-web-api

【讨论】：

谢谢，请注意我添加的解决方案的屏幕截图。我已经阅读了链接，但它仍然没有解决我遇到的问题:(