你追踪过OData的演变吗？你是在问“0”吗？OData（开放数据协议）适用于查询和更新数据的一项Web协议。它提供一种解锁数据的方式，将其从竖井中解放出来，这个竖井目前存在于应用程序之中。它通过定义通用模式集来实现同基于HTTP、AtomPub和JSON的数据进行工作。最初由微软提倡，OData已经赢得了众多追捧者。例如，IBM通过OData链接eXtreme Scale REST数据服务与客户端。此外，eBay利用OData通过eBay Finding API支持可用物品搜索，在开放数据协议中使用查询语句和格式。其他高端用户还包括Facebook、Netflix和Zillow。

　　微软Group Program经理Lance Olson抽空就OData的最新之处和未来方向接受了访问。

　　Q：简要说明什么是OData？什么时候开始创建的？为什么创建？

　　OLSON：OData始于微软的一个项目，现在叫做WCF数据服务。我们正字寻求一种更加简单的方法来处理数据，主要是通过服务接口进行。我们注意到，目前很多接口，无论是基于SOAP、REST还是别的都在交换数据时使用不同的模式。这种方法随后返回一大堆客户记录。你随后可以决定添加分页支持。你希望将结果捆绑在一个网格中，并对数据排序。最后，决定想要查询的东西，通过比如邮政编码来查询。

　　这种方法引起两个关键挑战。

　　首先是，没有创建泛型客户端的途径，而这些和API紧密联系，因为它不知道参数的顺序或者模式被使用的顺序。因为不能创建泛型客户端，你必须为每一个你希望暴露的API创建客户端。简单的基础HTTP API可以实现，但其仍旧很昂贵。逐渐增多的多样性客户端与这些API通信加剧了这个问题。

　　这种模式的第二个问题是它迫使开发人员进行很艰难的权衡。我应该暴露多少个查询？你必要在暴露每一个你能想到内容和少暴露一些，从而削弱服务之间协调。前者导致API 需要管理的界面的增加，后者会导致我们通常所说的“数据竖井”，也就是关键数据在特定模式中锁定，其他应用不能够简单应用，因为它没有以一种需要的方式暴露给这个应用。服务试图比单一应用要获得更长久一些，因此你需要以一种方式设计API，使其能够持久，所以如果你发现你需要添加服务借口的新版本可不太好办，比如创建新的客户端。在很多案例中，服务开发者和客户端开发者并不是同一个人，因而改变服务接口简直就是不可能的事情。

　　通过OData，我们采取不同的方法。取代创建客户端签名和参数，我们问了如下的问题：“如果你将数据集作为源处理，并为最频繁使用的操作定义模式，像查询、分页、排序、新建、删除和更新，服务接口因该是什么样子的？” 这也就导致OData的创建。OData解决了上面提到的关键服务设计挑战。最重要的是，OData让客户端应用和库可以立即编写，而且任何OData服务端点都可以重用。这也促成了一个更加广阔的客户端生态系统，从Windows上的.NET到Linux是上的PHP、Java以及iOS上的Objective-C等等。在微软，它也让我们可以比通过添加对产品的支持的传统服务接口更进一步。

　　随着时间的推移，我们继续看到消费者在更广阔的场景中使用这项协议。它的增长很清晰，我们需要能够同协议进行沟通。于是，在2009年秋天，我们发布了OData网站，开始在微软Professional Developers 会议上探讨OData。

　　在《Odata的黄金时间（下）》中，我们将继续为您介绍微软在Odata中所起的作用以及未来发展。