单独项目中的MVC解决方案中的Web API
我正在创建一个新的MVC4项目，研究让我相信，通过web API框架而不是控制器动作，现在可以更好地实现从javascript到服务器端的通信。 我的理解是否正确？
我假设我可以在Web API和MVC控制器之间共享我的所有属性等等，所以对我来说这似乎不是一个巨大的改变。
当我设置应用程序时，我喜欢将组件分解到项目中。 我的计划是有一个MVC项目和一个Web API项目。 但是我遇到了问题。 例如，我已经结束了2个应用程序，分开的路由设置等等。
所以我的问题是，在MVC应用程序中，应该将Web API框架放在同一个项目中，还是应该将Web API分离为自己的项目并解决问题？
不幸的是，你错了 - 我假设我可以在web api和mvc控制器之间共享我的所有属性等，所以在面对它时，对我来说这似乎不是一个巨大的改变。
Web API和MVC所使用的许多概念，即使乍一看类似，但实际上并不兼容。 例如，Web API属性是System.Web.Http.Filters.Filter ，MVC属性是System.Web.Mvc.Filter - 它们不可互换。
同样适用于许多其他概念 - 模型绑定（完全不同的机制），路由（Web API使用HTTPRoutes而非Routes，即使它们都在相同的基础RouteTable上运行），依赖关系解析器（不兼容）等等 - 尽管类似表面，在实践中是非常不同的。 而且，Web API没有区域的概念。
最终，如果你所做的一切都是为了提供JSON内容的“新潮流”方式，那么在进入这条道路之前要三思。 我当然不会推荐重构任何现有的代码，除非你真的正在寻找拥抱HTTP并以RESTful方式构建你的应用程序。
这一切都取决于你在建什么。 如果您正在开始一个新项目，并且您只需要提供一些JSON来简化您的Web应用程序 - 如果您愿意接受一些潜在的重复代码（如上面提到的那些代码），Web API可以轻松托管与ASP.NET MVC相同的项目。
如果您打算为您的在线服务构建适当的API，那么我只会将Web API分离为单独的项目 - 可能会被外部客户或各种设备使用 - 例如为您的移动应用程序加油。
IMO，安全和部署应该推动你的决定。 例如，如果您的MVC应用程序使用表单身份验证，但您有兴趣为您的API使用基本身份验证（使用SSL），单独的项目将使您的生活更轻松。 如果您想在www.example.com上托管您的网站，但将您的API作为api.example.com（与www.example.com/api）托管，单独的项目将使您的生活更轻松。 如果您将项目分开并相应地子域名，并且您打算从MVC应用中利用自己的API，则必须弄清楚如何处理客户端调用API的相同原始策略问题。 常见的解决方案是利用jsonp或CORS（如果可以的话）。
更新（3/26/2013）：官方CORS支持即将到来：http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API
经过一定程度的经验（为应用程序和mvc创建API）。 我主要都是这样做的。
我为来自其他客户端或其他设备（Android / IOS应用程序）的api调用创建了一个单独的项目。 其中一个原因是因为身份验证不同，它是基于令牌的（保持无状态）。 我不想在我的MVC应用程序中混用这个。
对于我的javascript / jquery api调用我的mvc应用程序，我喜欢将事情简单化，以便在我的MVC应用程序中包含一个web api。 我不打算使用javascript api调用进行基于令牌的身份验证，因为嘿，它在同一个应用程序中。 我可以在API端点上使用[authorize]属性，当用户没有登录时，他不会获取数据。
此外，在处理购物车时，如果您希望在会话中存储用户购物车（虽然未登录），但如果您通过JavaScript代码添加/删除产品，则还需要在API中包含此功能。 这将确保您的API有状态，但也会降低MVC-API的复杂性。
链接地址: http://www.djcxy.com/p/20377.html