APP 对决 Web3S：探索 RESTful 协议之路

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

Atom 发布协议是利用 HTTP [RFC2616] 和 XML 1.0 [W3C.REC-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）（我是指一般意义上的，并不特指 XML Schema），再加上某种形式的搜索（Search），以及通常跟 CRUD 相当类似的操作方式。因此，很自然就想到如何通过单一的协议来统一访问所有的服务。我们首先尝试了 APP。这是一个商业决定，Live 做的是服务业务，而不是协议或者开发工具业务。我的职责要求我不应理会人们通过什么浏览器来访问 Live、我们的合作伙伴 / 客户用什么语言来开发软件、他们运行什么操作系统等等。我的职责要求我注意的是，我们要让尽可能多的人写出尽可能多的软件来访问 Live 服务。 因此对我们来说，所有的协议问题只是一道门槛。这道门槛不能给我们带来任何收入。而且我们不担心锁定用户的问题。至少给我下指令的人（你好，George！）非常清楚锁定用户的日子已经一去不返了。未来显然属于将各种服务联结到一起的做法。也就是说，没有人会将他们所有的数据和服务等等，全都放在 Live 上。这不可能。即便我们做任何事都做到最顶尖，我们仍然无法获得用户的全部数据和服务。因此我们要想成功，就必须说服用户将他们的一部分数据 / 服务交给我们，然后我们让存放在我们这里的数据 / 服务通过简单到不能再简单的方式，跟用户存放在其他地方的数据 / 服务联结起来。

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

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

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

来自微软的 Dare Obasanjo 在题为《为什么 GData/APP 无法成为通用的 Web 编辑协议》的文章中解释了微软在 APP 中发现的问题，以及因此而（可能）导致微软另立门户，开发一个新协议。在文中 Dare 用很长篇幅解释了 APP 由于协议的约束而存在多处局限，特别是：

与非微内容（microcontent）的数据模型不匹配：ATOM 数据模型很适合用于表示创作的（authored）内容或者微内容，诸如博客文章、链接列表、podcast、在线相册和日历事件等等。在这些情形中，每个 Atom 条目要有一个 ID、一个标题、更新时间、若干作者和内容文本，这些需求都能够很好地满足，而且这样做很有道理。但另一方面，仍然有很多在线数据并不适合这个模型。

而且

缺乏对条目（item）中的一个域（field）进行更新这种小粒度更新的支持：前面已经说过要实现对一个条目的编辑需要用新条目来替换整个旧条目。客户与服务器之间的交互的规定在当前 APP 草案的第 5.4 小节，后面作了一些摘录。

最后

对分层结构的支持很弱：ATOM 数据模型并不直接支持嵌套和分层。你可以有一个媒体资源或者资源条目的集合，但资源条目自身不能包含资源条目。也就是说，如果你想要表示一个含有子条目的条目，则子条目必须通过链接来引用，而不能内嵌在条目中。如果考虑到 ATOM 的博客联合（syndication）和博客编辑的背景，这样做是有道理的，比如在 feed 中或者编辑文章的时候把所有评论都直接包含在条目里，就不是一个好主意。但另一方面，当你要表示一个直接的父 <-> 子层次关系，要是把子元素定义成一个独立的可定位资源，对客户来说就很繁琐，客户不得不总是发出两次甚至更多次调用才能得到所需的数据。

属于 IETF APP 工作组的 Bill de hÓra 对 Dare 的说法回应道：

原则上讲，我很欢迎协议的实现者们根据他们的需要反过来推动 ATOM 协议的发展。然而，声称 GData/APP 已经失败实在是不知所云，特别是提到的问题，有些是被审慎地排除在设计目标之外的（就目前而言）。如果这些就是微软遇到最严重的问题，我会很惊讶于目前 APP 的总体设计情况良好。根据他的思考的深度和所提到的微软内部的讨论，我更惊讶于 Dare 竟然没有提到以下两个问题：1、更新的断点续传（Update resumption）：有的客户需要将数据分成小片段来上传的能力。除开用户体验和节省带宽的理由，这对有些收费方式来说也很重要；不然用户要为每次上传失败买单。APP 从未涉及这个方面的支持；虽然用更普通的 HTTP 也可以做到，但要想得到合理的客户支持，你至少应该要求把它写进 RFC。2、批量（batch）和 multi-part 更新：ATOM 语法工作组已经考虑过这项特性但决定放弃。原因是要处理批量上传（或称作“打包运输（boxcarring）”）会变得难以预计的复杂。“发送一批条目”说起来很简单，但事实并非如此。不过未来仍然应该再继续考虑这些问题。

Joe Gregorio （另一位主要的 APP 贡献者），在 Yaron 的文章后的评论中问道：

我更希望知道的是，为什么当你遇到这些问题的时候，不把它们拿到工作组里讨论？显然当你开始搞 Web3S 的时候 APP 协议还没定案，如果你认为你发现了 APP 的真正弱点，虽然后续讨论证明你是错的，为什么不在我们发布协议之前提出来？

IBM 的 Sam Ruby ， RESTful Web Services 的作者之一，认为这个打算支持“结构化的、数据定义的和可搜索的 Web”的协议，根本没有支持 Web、数据定义和搜索：

这份文档中定义了两个新媒体类型（Application/Web3S+xml 和 Application/Web3SDelta+xml）、两个新 URI 协议和一个新 HTTP 方法（UPDATE）。我没有找到任何对二进制数据的讨论，事实上所有东西都是用 XML infoset 的语言来定义的。既然所有数据都必须属于某个命名空间，而这些命名空间必须用新的 URI 协议来定义，那么我们可以得出结论，没有任何现存的 XML 文档可被 Web3S 直接支持。Web3S 数据更进一步被局限为一个自我封闭的树。Web3S 中完全没有超链接的一般概念，无论是对外部数据的超链接，还是指向树中另一部分的超链接。要遍历这些数据，你必须了解程序所采用的特定的数据定义。

XML 的发明者之一 Tim Bray批评了 Web3S 的产生过程。

Yaron 恕我直言，人们第一次听说 Web3S 竟然是来自 Dare 这篇试图说明 APP 的缺陷的文章，这真是非常不幸。更不幸的是，这篇文章表明了 Dare 没有读过也不理解 APP 协议。大家，特别是我一开始对他非常严厉；但这篇文章相当不知所云。在我看来，Dare 应该不是大家所猜测的那样。 同学们，如果你打算去微软工作，你就要准备好被人习惯性地猜疑。要回头去改变导致现在局面的历史已经太晚了；现在连 MBA 基础课程都会教你不要相信微软。要么学会处理这种局面，要么就换份工作吧。

当初其他团队正在积极地公开设计一个通用的基于 REST 的协议，如果 Live 团队能尝试跟他们沟通就好了，但过去的事已经无法挽回。

David Ing 对微软的工作做了一些有趣的观察，他对整个事件总结道：

有意思的时代。我不清楚 APP 会建成一座什么样的教堂，但我认为会有人想知道怎样在 APP 内部直接解决这些需求，而不是从外部。看起来世界上不需要给这么几个 HTTP 谓词再定义另一个简单的协议，但我认为微软找到了一条直截了当的路线来解决他们的需求，并且根据他们的现有资源采取了达到目标的最快方式。这可能最终被证明是 Web 前进路线上的一条小岔路，但目前来说并不是没有价值的。

确实，有意思的时代。

查看英文原文： APP vs. Web3S: the Quest for a RESTful Protocol