我正在设计一个分布式应用程序，它将由RESTful服务和各种客户端（Silverlight，iOS，Windows Phone 7等）组成。现在，我正在确定应该使用哪种技术来实现我的服务，WCF数据服务（OData）或ASP.NET MVC 4随附的新ASP.NET Web API。
我在线上观看了一些演示，现在我倾向于WCF数据服务，这主要是因为URI内置的过滤机制和本机超媒体功能。我唯一看到的缺点是Atom Pub规范相对于POX的冗长。
在做出决定之前，我应该对这两种技术有什么了解吗？为什么有人会选择WCF数据服务上的ASP.NET Web API？
Answers:
这是一个主观的问题，所以这是一个主观的答案。IMO，WCF对于简单的RESTful服务有太多的开销。另一方面，Web API专为RESTful服务而设计。
我同意戴夫·沃德（Dave Ward）的观点。查看他的博客以获取更多信息。
长期以来，我一直承受着从WebForms项目中的ASMX迁移到WCF的压力，因为接受WCF的复杂性主要是因为我对JSON序列化的灵活性降低了。相比之下，我已经开始将我的一些项目从ASMX转换为Web API，并且对Web API替换ASMX的便捷程度感到满意。
我相信Microsoft终于在ASMX的简单性和WCF的Web API功能之间找到了很好的平衡。
MediaTypeFormatter格式化回复的方式。有关示例，请参见code.msdn.microsoft.com/Contact-Manager-Web-API-0e8e373d。
当前，WebApi和WCF数据服务之间还有其他主要区别，似乎从未有人提及。我希望MS能够发表一篇很好的文章来比较两者。
我一直在关注OData和WebApi。我总是发现一些主要区别。
首先，我不确定您的老板所说的“ MS支持WebApi”是什么意思，也就是说他们不支持OData？海事组织，他们都支持，目前有一些最小的重叠。Windows Azure数据市场使用OData公开其数据，Azure表存储使用OData，SharePoint 2010允许对其数据进行OData查询，MS的其他产品（例如Excel PowerPivot）也支持该数据。当涉及到关系数据时，它是一个非常强大的查询框架。而且由于它是RESTful，所以任何语言，框架，设备等都可以与其集成。
这是我喜欢的OData + WCF数据服务：
OData + WCF数据服务最终使客户端应用程序在通过Web查询数据时更具“表现力”。以前，我们总是必须使用ASMX或WCF来构建严格的Web API，这些API变得笨拙，并且每当UI需要稍微不同的东西时都需要不断进行更改。客户端应用程序只能指定参数来指示要返回的条件。或像我一样做并“序列化” LINQ表达式，然后将它们作为参数传递并重新水化为Expressions<Func<T,bool>>服务器上。其体面。完成了工作，但是我想在客户端上使用LINQ，并使用REST在Web上将其转换，这正是OData所允许的，并且我不想使用自己的解决方案“ hack”。
就像无需数据库连接字符串就公开“ TRANSACT SQL”一样。只需提供一个网址和哇！开始查询。当然，WebApi和WCF数据服务都支持身份验证/授权，因此您可以控制访问，根据角色或其他数据配置附加其他“哪里”语句。我宁愿在Web Api层中执行此操作，也不愿在SQL中执行此操作（例如构建视图或存储的Procs）。现在，应用程序可以自行构建查询，您将看到Ad-Hoc和BI报表工具开始利用OData并允许用户定义自己的结果。不依赖于对其控制程度最低的静态报告。
在Silverlight，Windows 8 Metro或ASP.NET（MVC，WebForms等）中进行开发时，您只需在Visual Studio中向WCF数据服务中添加一个“服务引用”，然后快速开始使用LINQ来查询数据并获得一个客户端上的“数据上下文”，这意味着它跟踪更改，并允许您将更改原子地“提交”回服务器。这与RIA Services for Silverlight非常相似。我本可以使用WCF数据服务而不是RIA服务，但是当时它不支持DataAnnotations或Action，但是现在可以了：) WCF数据服务相对于RIA Services具有另一个优势，即执行“投影”的能力来自客户。如果我不想从实体返回所有属性，这可以提高性能。具有“数据上下文”
因此，如果您具有具有关系的数据，则WCF数据服务非常有用，尤其是在使用SQL Server和实体框架的情况下。您只需很少的代码，就可以通过REST快速公开可查询的数据+操作（调用调用操作，即工作流，后台进程）。WCF数据服务刚刚更新。新版本发布。查看所有新功能。
WCF数据服务的缺点是您无法通过HTTP堆栈进行“控制”。我发现最大的缺陷IQueryable<T>在于返回Collections 的方法。与RIA Services和WebApi不同，您没有完全访问权限来开发IQueryable方法中的逻辑。在RIA Services和WebApi中，只要返回就可以编写所需的任何代码IQueryable<T>。在WCF数据服务中，您只能使用以下内容来附加“ Where”语句Expression<Func<T,bool>>拦截器方法。我发现这令人失望。我们当前的应用程序使用RIA Services，我发现我们确实需要控制IQueryable逻辑的能力。我希望我错了，我只是想念一些东西
另外，WCF数据服务也不能完全支持所有LINQ运算符。它仍然比WebApi支持更多。
WebApi呢？
到目前为止（据我了解），客户端（例如Silverlight，ASP.NET服务器端代码等）尚不支持“数据上下文”，因为WebApi并不真正涉及WCF数据服务/ OData等实体数据模型是。它可以使用IQueryable / IEnumerable公开模型对象的集合，但是一旦实体加载到客户端上，就没有主键/外键“导航属性”（即customer.Invoices）可以使用，因为没有“数据上下文”异步加载它们（或使用$ expand在一个调用中），并管理更改。您没有像在RIA Services或WCF Data Services中一样，在客户端上没有代码生成的实体数据模型的“表示形式”。我并不是说您不能/没有代表您数据的客户端模型，但是您已经手动填充了数据，并管理了通过Web检索到每个“客户”后将要设置的“发票”。这可能会变得棘手，特别是在所有异步事件发生的情况下。您不知道哪些电话会先返回。这在这里可能很难解释，但是只需阅读RIA Services中的“数据上下文”内容或WCF数据服务。因此，在处理Line of Business Apps时，这对我来说是主要问题。这主要基于生产率和可维护性。您可以完全构建没有数据上下文的应用程序。它使事情变得更加容易，特别是在Silverlight，WPF和现在的Windows 8 Metro中。将关系实体异步加载到内存中并具有Two-Binding非常好。
话虽如此，这是否意味着有一天WebApi可以在客户端上支持“数据上下文”？我认为可以。此外，借助更多工具，Visual Studio项目可以基于数据库架构（或实体框架）生成所有CRUD方法。
另外，我知道在使用WCF数据服务或WebApi时，我只是在.NET框架中提到.NET，但是我很清楚HTML / JS也是主要参与者。我刚才提到的是在处理Silverlight UI或ASP.NET Server-Side Code等时发现的好处。随着HTML5 / JavaScript中“ IndexedDB”的出现，我相信具有“数据上下文”和也可以使用JavaScript中的LINQ框架，从而使从JavaScript查询OData服务的功能更加容易（您现在可以将DataJS与OData一起使用）。另外，使用KnockoutJS也支持MVVM和HTML / JS中的绑定，将使它轻而易举:)
我目前正在研究要使用的平台。我很乐意使用这两种方法，但是由于我的下一个应用程序主要是关于Analytics（分析）（只读），并且我想要一个功能丰富的RESTful Api，因此我倾向于使用OData。我相信OData + WCF数据服务给了我，因为WebApi仅支持$ take，$ skip，$ filter，$ orderby over Collections。它不支持投影，包含（$ expand）等。我没有很多“更新/删除/插入”，并且我们的数据是相当相关的。
我希望其他人也能参与讨论并发表想法。我仍在决定，很想听听其他意见。我真的认为这两个框架都很棒。我想知道您是否必须选择，如果需要，为什么不使用两者。无论如何，从客户端开始都是建立REST调用。只是一个想法 ：）
我们相信，Web API为以后的OData服务提供了正确的平台，因此将主要在该平台上投资 OData服务器堆栈。当然，我们将继续在OData核心库和客户端中投入大量资源，但我们确实计划 减少对WCF数据服务（作为用于创建OData服务的堆栈）的投资。
所以，看来现在一切都足够清楚了
Web API和WCF数据服务均支持开箱即用的OData。使用WCF数据服务（WCFDS），它是自动的。使用Web API，IQueryable从控制器返回并用标记方法[Queryable]。这将使您获得$filter正在谈论的功能。而且，如果您采用这种方式，那么两者都可以通过放入accept=application/json请求标头来自动处理响应中的JSON 。与Web API相比，WCFDS的OData支持更多的OData关键字（尽管只$expand想到了关键字），但是我敢肯定，时间可以解决这个问题。
.NET客户端和HTML页面都可以轻松调用这两种选择，但是如果您喜欢LINQ，并且正在构建.NET客户端，则可以将WCFDS作为服务引用添加到您的项目中。这使您可以完全跳过所有HTTP业务，并直接查询集合。
最重要的是，没有什么可以阻止您将.svc文件放入ASP.Net MVC项目中。这不是一个非此即彼的主张。将数据服务添加到服务器将节省您编写大量控制器的需求，但也不会阻止您编写其他控制器。
换一种说法 ：
如果您希望快速公开数据模型（EDM或其他），而无需大量代码或业务逻辑，则可以使用WCF数据服务将使其变得非常容易，并且将是一个很好的起点。
如果要构建API，而只是想使用OData查询语法或格式来公开一些资源（和逻辑），那么ASP.NET Web API可能是最好的起点。
只需以最简单的方式进行说明，从基础协议中退一步，并从开发人员/用户的角度进行研究。Web API是Microsoft的一流的基于HTTP的Rest框架，而不是WCF。这意味着任何缺少的Rest功能，规范，都将添加到Web API管道中，而不必添加到WCF中。
是的，您可以在WCF中自己实现这些，但正如句子中所说，您需要自己实现这些。
就像今天的一个示例一样，使用OWIN可以为Web API实施2要素身份验证花费了不到15分钟的时间，OWIN主要是作为开放源代码项目开始的Authentication / Authorization nuget程序包。
当您使用技术堆栈时，使用Microsoft的一流堆栈将有很大的不同。您甚至可能在Github中拥有无数MS发布的示例代码和项目，您可以简单地复制它们并在自己的项目中抢先一步。您在每个级别，文档，代码示例，功能集，支持，帮助程序api上都会有所不同。
因此，如果您想构建基于Restfull HTTP的应用程序，我的简单建议就是使用Web API（或可移植性的ASP.NET Core），并远离WCF。如果协议不是HTTP，而实际上不能为HTTP，则使用WCF。
这是此问题的TL; DR答案。
WCF是使用WEB API螺丝刀进行数据通信和传输的瑞士军刀：WCF可以完成WEB API可以做的所有事情，但是，如果您需要更多（例如，使用TCP协议），则可以使用WCF。
这是一个很好的比较。
使用WEB API的第一个原因是它是轻量级的。这意味着它更易于实现，易于学习，易于维护等。它是专门为Web设计的，该Web需要通过HTTP进行RESTful Web服务。它做到了，而且做得很好。如果这是您所需要的，则可能是WEB API。
此外，它是开源的（如果您在乎）
WCF的功能远不止WEB API：它支持多种传输协议，多种交换模式（WEB API需要与SignalR或Web套接字集成），可以在WSDL中描述SOAP服务，具有其他安全功能等等。如果需要此附加功能，请使用WCF。
OData就是
一种开放协议，允许以简单和标准的方式创建和使用可查询和可互操作的RESTful API。来源：http：//www.odata.org/
换句话说，它只是针对RESTful HTTP请求的特定语法的标准化。它将提供与任何协议相同的好处。至少从2013年开始，WCF和WEB API都允许使用OData。因此，可能不值得担心OData。