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前进路线上的一条小岔路，但目前来说并不是没有价值的。

　　确实，有意思的时代。