对决探索协物业

她第一件事都是连上WiFi上。就算出去吃饭 标准化的资源发布和协议可以带来很多好处，因为它提高了达成跨组织的互操作和普遍理解的机会。虽然发明出XML作为基础格式已经让这方面有了一点提高，但XML有些过于空泛，在描述一些更确切的属性如集合和集合元素上，没能设立一些得到广泛认同的基本准则。将XML格式和通用的HTTP协议相结合所形成的RESTful，有望成为一个共同的基础。目前的确有若干协议着眼于这个问题。最早也可能是最成熟的是ATOM发布协议(ATOM Publishing Protocol，APP)，它是一个IETF标准，目前已接近定案。APP在最终草案中定义如下：以下是引用片段：

Atom发布协议是利用HTTP[RFC2616]和XML1.0[C-xml]对Web资源进行发布和的应用层协议。本协议支持Web资源的创建，并为以下概念提供设施：

集合(Collections)：资源的集合，可以获取整个集合，也可获取其一部分

服务(Services)：发现和描述集合。

(Editing)：创建、更新和删除资源。

APP和当前许多协议的不同之处在于，服务器在如何处理来自客户的请求上，被给予了充分的自由。

APP还定义了一个标准扩展模型，以使其更便于使用。事实上Google就是一个例子，他们利用这个模型开发了Google Data API (GData)作为读写Google的各种服务，如Google Base、Google Calendar等的通用协议。

然而，微软似乎不喜欢APP，他们决定发布自己的叫做Web3S (“Web Structured, Schema’d Searchable”)的协议。微软员工Yaron Goland最近在博客中介绍了这个协议：

以下是引用片段：

Live平台上的大多数服务都遵循非常类似的设计模式，我最初称之为S3C。S3C是个缩略词，表示结构化(Structured)的数据，加上某种形式的数据定义(Schema)(我是指一般意义上的，并不特指XMLSchema)，再加上某种形式的搜索(Search)，以及通常跟CRUD相当类似的操作方式。因此，很自然就想到如何通过单一的协议来统一访问所有的服务。我们首先尝试了APP。这是一个商业决定，Live做的是服务业务，而不是协议或者开发工具业务。我的职责要求我不应理会人们通过什么浏览器来访问Live、我们的合作伙伴/客户用什么语言来开发软件、他们运行什么操作系统等等。我的职责要求我注意的是，我们要让尽可能多的人写出尽可能多的软件来访问Live服务。

因此对我们来说，所有的协议问题只是一道门槛。这道门槛不能给我们带来任何收入。而且我们不担心锁定用户的问题。至少给我下指令的人(你好，George!)非常清楚锁定用户的日子已经一去不返了。未来显然属于将各种服务联结到一起的做法。也就是说，没有人会将他们所有的数据和服务等等，全都放在Live上。这不可能。即便我们做任何事都做到最顶尖，我们仍然无法获得用户的全部数据和服务。因此我们要想成功，就必须说服用户将他们的一部分数据/服务交给我们，然后我们让存放在我们这里的数据/服务通过简单到不能再简单的方式，跟用户存放在其他地方的数据/服务联结起来。

换句话说，这完全取决于互操作性，互操作越简单，我们就越成功。因此我们梦想能有一个满足S3C模式的协议。非常流行，受到广泛支持的协议。一个我们可以直接采用，立刻开始做生意(构建伟大的服务)开始赚钱的协议。

于是我们首先尝试了APP。它是现在最热门的。雅虎、Google……每个人都爱它。正如Dare在他的最新文章中所说，微软已经采用了APP，并将继续采用APP，只要这样做有积极意义。事实上，当我们环顾四周，我们无法发现任何能真正满足我们需要的协议。

因为我的上司讨厌S3C这个名字，因此我们将其改名为Web3S，并用这个名字发布了它。协议的第一段解释了我们的需求。我还发表了一篇常见问题解答解释了Web3S的基本设计原理。理所当然地，我在第一个问题(第2.1小节)解释了我们不采用ATOM的原因。