WCF数据服务（OData）与ASP.NET Web API？超媒体？

我正在设计一个由REST服务和各种客户端（Silverlight，iOS，Windows Phone 7等）组成的分布式应用程序。我已经准备好决定要使用WCF数据服务（OData）来实现我的REST服务，但是现在MVC 4 Web API令我质疑该决定。

我喜欢OData的是免费获得的URI查询和超媒体功能。我不喜欢OData有效负载的详细程度；导线上出现了许多不必要的字符。

我喜欢Web API的原因是有效负载更加简洁，并且具有OData的URI查询功能，但是似乎缺少超媒体（至少是开箱即用的）。我的老板也在推动Web API的开发，因为“微软的力量正在支持它，而OData并没有受到人们的青睐。”

所以我有两个问题：

1）谁能评论Web API和OData的支持/牵引？

2）是否期望Web API在发布时间之前就本机支持超媒体，或者我应该研究任何现成的实现或示例？

谢谢！

Web API执行odata。请参阅Scott Guthrie的博客文章。特别：

查询组成：Web API使您可以轻松地支持通过OData URL约定进行查询。当从Web API返回IQueryable类型时，该框架将自动为其提供OData查询支持-轻松实现分页和排序。

我还认为，在许多情况下，同一类可以是传统的WCF类和Web API类，它们绝对不是互斥的。

Web API更原生地利用了http协议。Odata是许多大公司都拥护的开放标准。我只能根据自己的经验与Odata进行交流，最近才发现Web API并进行了一些研究。

OData很酷，因为它是实际标准。您可以轻松创建数据库并通过HTTP公开它。这意味着您可以在没有任何配置的情况下遍历表结构（我这么说就是这样）。您还可以通过包含少量LINQ的URL运行查询：

/products/orders/[put some linq-ish query here]

这可以说是好是坏。身份验证是标准的并已构建。

从我的角度来看，Web API更有趣。它利用了HTTP功能（错误消息等），对于真正的RESTful请求而言，它更“原生”。我确实没有玩太多。.但是我已经阅读了一下，并且有点“听说” MVC和Web API可能有一天会“结婚”，也许好，也许坏。

当我使用OData时，我创建了一个存储过程，将其映射到实体表面，配置了一个强返回类型，然后将其连接到URL请求和BANG，我的RESTful请求映射到了键入结果存储过程。这非常简单，而且我能够完全得到所需的东西。

结束语 我没有太多细节可以使用WCF API，但是我想说这是进行客户端开发的方法，因为它是一种更纯粹的REST方法。如果您要或多或少地进行“直接”来回调用并检索“视图模型”，它将提供更多的本机交互。

另一方面。如果您要基于客户端交互对数据进行复杂的查询，并且希望“构建”查询逻辑并将其作为参数传递，那么Odata可以工作。

我的观察方式是，如果我需要以结构化格式（即表/关系结构）公开数据，然后直接从客户端查询它，那么Odata会工作得最好。允许“其他”访问数据（使用正确的身份验证等）也很有用，这就是为什么它遵循OData协议的原因

如果您希望在RESTful请求中指定URL（/ products / orders / 22，并从“隐藏”的托管代码和数据结构中创建复杂的“结果集”，并且还可以从HTTP响应消息中受益，则可以Web API可能是最好的选择。

再次，这都是来自研究和玩弄。我还没有在生产/功能完善的应用场景中实现过。我认为他们都有长处和短处，而且肯定存在一些重叠

从超媒体的角度来看，绝对是Web API。基于AtomPub的OData只是使用HTTP公开数据库的一种方式，您只能获得有限的一组预定义状态传输（CRUD）。另一方面，超媒体服务就像是为客户端量身定制的应用程序。使用Web API，您可以嵌入所需的所有链接，还可以使用OData查询语法。实际上，如果您愿意使用HTML作为基本格式，则Microsoft堆栈中最好的超媒体解决方案是ASP.NET MVC。