在这篇文章中，我想到了OData，特别是它来自哪里，以及为什么它看起来和行为都像它。我还考虑了为什么我认为这是一个很好的协议，像SAP这样的组织可以接受。或者像有些人写的那样（让我咬牙切齿）"oData"。不过，并不像布伦顿·奥卡拉汉写的"O'Data"那么糟糕，只是为了惹恼我。总之，更严肃的是，大淘客网站，我最近一直在考虑OData，它是一个完全形成的、可扩展的CRUD+Q服务器，您可以免费获得它，只需一个小小的咒语，就可以看到SAP云平台应用程序编程模型工具的神奇之处。我也在考虑OData，因为Holger Bruchelt最近的一篇文章"OData之美"–很好的一个Holger.

OData基础

OData是一个协议和一组格式。它是非常面向资源的，而不是面向服务的，这对我来说是一件非常好的事情。将代表性状态传输（REST）看作是一种体系结构样式，而不是一种特定的协议（不是），您将遇到这种样式包含的各种设计特性。不过，对我来说，关键的特性是统一的接口——有一小部分固定数量的动词（OData操作）和一组无限多的名词（资源），动词在这些名词上进行操作。这些OData操作非常清晰地映射到我们所熟悉和喜爱的HTTP方法上，并在语义级别上理解这些方法：

还有更多（例如，使用补丁进行合并语义，或者在httppost请求中批处理多个操作），但基本上就是这样。我们有一组标准的CRUD+Q操作，在考虑资源操作时，这些操作涵盖了大多数用例。对于边缘案例，考虑资源和它们之间的关系会太麻烦，有一个函数导入机制（我和它有一个爱恨关系，因为它很有用，但也相当面向服务，因此不透明）。

除了协议本身，OData操作是在数据的形状上执行的。我不是说格式——那是分开的，也是多方面的。OData格式与资源的多种可能表示的RESTful思想有关，有不同的风格——主要是基于XML和JSON的。我所说的"形状"是指OData资源中的数据是如何表示的。

我经常说的一件事是，如果某件事情足够重要，它应该是可寻址的。更具体地说，业务数据应该是可寻址的，因为元素应该有地址，而不是隐藏在某种不透明的web服务端点后面。在像OData这样的HTTP协议中，这些地址是url。数据的形状可以从这些URL地址的组成方式中看出

一些绝对的RESTful纯粹主义者可能会认为URL应该是不透明的，我们不应该从它们的结构中暗示意义。对我来说，这是一个有效但极端的立场，必须在绝对纯洁的美丽理论和现实生活实用主义的奇妙效用之间保持平衡。

而数据本身的形状是一致的和可预测的，这允许这种情况发生。为了了解这个形状是什么，以及它是如何工作的，我想简单地看一看小田的起源。这是我几年前在一次关于OData的会议上给出的一个图像：

OData的原始历史

我建议，大数据分析过程，如果从大局来看，OData的起源可以追溯到1995年，随着元内容框架（Meta Content Framework，MCF）的出现。这是Ramanthan V Guha在苹果高级技术小组工作时创建的一种格式，它的应用是提供关于网站和其他基于网络的数据的结构化元数据，提供人类处理的信息的机器可读版本。

几年后，Dan Libby在1999年与Netscape的Guha合作制作一个我们很多人还记得的格式的第一个版本，也许我们大部分人仍然直接或间接地使用RSS。RSS的第一个版本建立在MCF思想的基础上，专门设计用来描述网站，特别是weblog风格的内容——随着时间的推移发布的条目，通常有时间戳、标题和一些内容的条目。RSS最初是为与Netscape的"我的Netscape网络"一起工作而编写的，它允许来自不同来源的内容的组合（参见规范：rss0.9（Netscape）了解一些背景信息）。RSS代表rdfsitesummary，因为它使用资源描述框架（RDF）来提供元数据语言本身。（多年来我一直对RDF着迷，但我将把它留到另一个时间。）

我将在紧接着的这段时间里快速前进，云上，因为它涉及到RSS的变化，因为它在竞争派系手中遭受的痛苦，主要是由于一些当事方不愿意在公开过程中合作，这并不是一段特别愉快的时光（我记得，我当时就在附近，接近正在进行的活动，认识一些相关的人）。但在这段时间里，几乎不可避免地出现了一个叫做Atom的新举措。与RSS一样，Atom的关键在于描述博客内容的结构，实际上这种结构非常接近RSS的样子，然后，一系列代表博客帖子本身的项目：

和RSS提要一样，Atom提要（也用于机器消费）以XML形式提供，与基于HTML的博客本身（当然是供人类使用）并行。

几年后，即2005年，Atom格式成为一个互联网工程任务组（IETF）标准，特别是rfc4287，后来被称为Atom联合格式：