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