Edit
ServiceStack现已添加自动查询 http://docs.servicestack.net/autoquery这是我们实现数据驱动服务的方法，可以避免OData 提出的陷阱和反模式 http://docs.servicestack.net/why-not-odata.
ServiceStack是否支持OData？
No.
反正也不直接。如果有人看到 OData 的任何价值，他们可以自由添加必要的功能作为可选功能Plugin http://docs.servicestack.net/plugins- 但它永远不会内置到 ServiceStack 核心中。
不良的开发实践
OData 不太适合 ServiceStack强烈反对过度抽象 http://www.infoq.com/articles/interview-servicestack以及我们认为的“神奇行为”的经典例子 https://twitter.com/coates/status/268767167686787072:
当您的精美框架发挥神奇作用时，您节省的每一分钟
帮助您节省未来十分钟的调试成本。不值得。
我们认为依赖黑盒斑点的神奇行为永远不会经受住时间的考验。历史上每当我们使用这个（例如ADO.NET 数据集 http://msdn.microsoft.com/en-us/library/8bw9ksd6%28v=vs.71%29.aspx, ASP.NET 动态数据 http://msdn.microsoft.com/en-us/library/ee845452%28v=vs.100%29.aspx）我们很快就遇到了这些框架固有的不灵活的限制，这些框架无法发展以支持新的开发人员实践、范式和技术，而它们的设计初衷并不是支持这些，从而导致它们很快被弃用，取而代之的是更新的框架这样可以。这是我们不希望提倡的重写周期。
宣扬不良网络服务实践
OData 还促进了您所处的反模式暴露内部实现细节您的服务的隐式服务契约与底层 RDBMS 表紧密耦合，使您能够对未来服务的缓存性、重构或版本能力进行有限的控制。
这类似于传递数据库连接字符串，一旦生产中的客户端绑定到它，表的结构就会被冻结，从而抑制发展现有数据库表的能力，因为它可能会破坏现有客户端。 ServiceStack 的建议是将您的客户端绑定到定义良好的服务层，您可以自由地重构其实现。
总而言之，OData确实提供了丰富的功能，但我个人不建议在您无法控制且可以部署客户端和服务器的内部网之外使用它。
WebApi 是通过返回对 oData 隐式支持的最佳选择IQueryable<T>界面。
仅用于仅 Microsoft 技术
Web/远程服务（尤其是 SOA）的主要好处之一是，它为您希望公开的任何功能提供了一个与技术无关且可互操作的外观。虽然OData http://www.odata.org/是一个开放标准，该技术本身基本上仅被微软采用.NET 相关举措 http://www.odata.org/ecosystem.
OData 速度慢
OData 发现本身很慢 https://coldie.net/?tag=servicestack（这与我们的核心目标相悖）并且缺乏对实施的控制使得很难干净地实施诸如缓存之类的性能增强技术。
具体例子
我在评论的最后给出了一个具体的例子来说明为什么 oData 是一个坏主意IQueryable 是紧耦合 http://blog.ploeh.dk/2012/03/26/IQueryableTisTightCoupling/我将在此处重复该帖子以进行保存：
Web 服务接口的整体思想是公开一个
与外界技术无关的可互操作 API。
公开 IQueryable/OData 端点可以有效地耦合您的
无限期地使用 OData 的服务，因为您无法切实可行
确定现有客户端绑定到什么“查询空间”，即什么
您需要冻结/支持的现有查询/表/视图/属性
无限期地。在公开任何实施时，这是一个问题
API 的表面积，因为它限制了您添加自己的 API 的能力
其上的自定义逻辑，例如授权、缓存、监控、
速率限制等。并且因为 OData 非常慢，所以您会遇到
早期出现性能/扩展问题。缺乏控制
端点，意味着您实际上正在进行重写：https://coldie.net/?tag=servicestack https://coldie.net/?tag=servicestack
让我们看看摆脱 oData 提供商的可行性如何
通过查看来自 Netflix OData 的现有查询来实现
应用程序编程接口：
http://odata.netflix.com/Catalog/Titles http://odata.netflix.com/Catalog/Titles?$filter=类型%20eq%20'电影'%20and%20(Rating%20eq%20'G'%20or%20Rating%20eq%20'PG-13')
该服务现在有效地耦合到名为的表/视图
“标题”有一列名为“类型”的列。
如果您不使用 OData，它会如何自然地编写：
http://api.netflix.com/movies? ratings=G,PG-13 http://api.netflix.com/movies?ratings=G,PG-13
现在，如果出于某种原因您需要替换
现有的服务（例如更好的技术平台已经出现，
它运行太慢，您需要将此数据集移动到
NoSQL/Full-TextIndexing-backed sln）需要付出多少努力才能
替换 OData impl（它有效地绑定到 RDBMS 模式）
和 OData 二进制 impl）到更直观的与 impl 无关的查询
以下？这并非不可能，但因为它非常困难
为新技术实现 OData API，即重写 + 破坏
现有客户往往是首选。
让内部实现决定面向外部的 url
当事情需要时，结构是打破现有客户的可靠方法
改变。这就是为什么你应该在 Cool URI 后面公开你的服务，
即逻辑永久 URL（不受实施阻碍）
不会改变，因为您通常不想限制
您服务的技术选择。
如果您想提供临时的“探索性”，这可能是一个不错的选择
服务”，但这不是我想要的外部客户
绑定到生产系统中。如果我只想限制它
使用我的本地 Intranet 与仅仅提供相比有什么优势
输出只读连接字符串？这将允许其他人使用
他们最喜欢的 Sql Explorer、Reporting 或任何其他会说话的工具
SQL。
Update
Netflix 刚刚停用其 OData 目录，于 2013 年 4 月 8 日生效 http://developer.netflix.com/blog/read/Changes_to_the_Public_API_Program.
添加了新答案为什么我们建议使用干净、定义良好、未受污染的 DTO 来定义任何远程服务 https://stackoverflow.com/a/15369736/85785，这是使用 OData 无法推广的远程服务最佳实践。
关于原因的好文章OData 等基于通用的 API 比同等的基于意图的 API 更脆弱、更复杂且更难使用 http://mathieu.fenniak.net/stop-designing-fragile-web-apis/.
