Google的GData/Atom发布协议相对于微软限制太多

Dara Obasanjo写了一篇关于Google Data API作为一个通用的协议（Google关于Atom Publishing Protocol的实现和一些扩展）的不足，并解释了Microsoft为什么无法支持GData或把GData作为标准的理由。

在简短的把GData称赞为“简单和一致的接口”之后，Dare Obasanjo叙述到“GData/APP作为一个通用的Web编辑协议是不妥的”。根据Obasanjo的说法“当你不局限于这些协议的设计初衷，即只为了编辑Blog这样的情况下，某些在Atom Publishing Protocol中的限制变的十分明显”。然而，Microsoft虽然没有提供对GData的支持，但提供了“类似REST的一种标准协议”，对于Microsoft的协议，Dara Obasanjo没有点名也没有讨论，不过他答应未来会发帖子进行讨论。

他指出了如下的限制：

数据模型不匹配，源于它们不是微内容：Atom的数据模型非常适合表述人为创造的内容或者微内容（译者注：用户所生产的任何数据都算是微内容），在诸如Blog日志、链接列表、Podcast、在线相册和日历事件这样的Web应用中。当表述“一个具有特殊结构的业务对象”的时候，组成Atom条目的大部分元素没有意义。第二，一个人不得不创建大量的专有扩展元素来注释atom:entry元素，以便处理业务对象中所有特定的字段。这就像，在一个圆形的孔里面试图去适应一个方形的木栓。如果你强行去弄，有可能会适合，但却要命的难看。

缺乏对条目字段粒度更新的支持：每个客户端需要自己负责确认在被下载的原始atom:entry元素中没有丢失任何XML。第二个问题就更严重，需要关心谁阅读了可编辑Web：通过无条件的签出来检查丢失更新的问题。如果条目在客户端下载后和试图提交改变之前被更改过，这个问题会引起数据丢失的情况。即使客户端在提交更改之前发出一个HEAD请求来比较ETag，也总是有可能更新发生在HEAD请求之后。在某个点之后，有可能出现“最近更新获胜”是合理的，这是因为现存的解决冲突的算法过于简单。不幸的是，这种方法也同样是失败的，由于Atom Publishing Protocol让客户端程序负责在atom:entry中的所有内容（的处理），即使它们只是感兴趣一个字段。

层级不足的支持：Atom数据模型是不能直接支持嵌套或层级的。你能拥有媒体资源或者条目资源的集合，但条目资源不能自我包含条目资源。这意味着，如果你想重复一个具有子条目的条目，那么它必须通过一个连接来引用而不是包含在内部。通过连接来引用有时候是有意义的，比如当你考虑到Blog聚合和Blog编辑这样的情况，直接把所有评论包含在Feed条目中确实不是一个好主意。然而从另外一个方面来看，当条目具有一个直接的父子层级关系的时候，而子条目需要通过它自己的资源地址来定位，对于客户端来说总是显得麻烦，因为为了得到它们需要的数据而不得不进行两次或多次的调用。

Bill de hóra 对这个帖子进行了回复，并针对Dare Obasanjo提出的局限性提供了一些可行的解决方案。另外，他也添加了两个问题到限制列表中，“以便让人觉得他是多么可靠”：

更新的重新占用功能：一些客户端需要能够分片段上传数据。从较差的用户体验和通常的带宽消耗来看，对于特定清单模型（更新的重新占用功能）是重要的；不那样的话，数据消费端就不得不关注每次失败的数据上传。APP根本不能说支持这些功能；通常情况下利用HTTP是可以做得到的，但是为了得到像样的客户端支持，至少需要提交为RFC标准。

批量和多部分上传：这个特性已经被考虑，atom语法工作组已经开始着手此事了。（需要这个特性的）原因是成批传送消息（即所谓的“boxcarring”）能带来意想不到的复杂处理方式。那就是，仅仅说“发送一堆条目”，简单得让人感觉有些靠不住。尽管如此，这个特性在未来，从某些方面看还是值得关注的。

James Snell和Joe Gregorio明显不同意这样的说法，他们指出，Dara Obasanjo提出的缺点完全不是缺点。James把Dare的帖子称作“无聊”，Joe问道：

使我怀疑他对于APP抱怨的时间是在APP将要获得RFC认可的时候。是什么原因突然让他说起葡萄酸来了？

Google已经明确地提供了一个简单而有效的API来访问他们的服务。他们表示，不想百分百地解决所有的使用情况，而是提供一个确实简单和一致的API来满足主要的80%的情况。我们倒是想看看，Microsoft为了提供一个针对Web的通用编辑协议（General Purpose Editing Protocol）而会提供一个什么样的RESTful协议。

查看英文原文： Google GData/Atom Publishing Protocol too limited for Microsoft 译者简介：朱永光，IT自由人和环境保护者，微软最有价值专家（MVP）和MCSD。他有14年的编程实践经历，5年软件构架和开发管理经验，擅长微软相关技术和产品，目前主要关注软件构架和开发框架，是 成都.NET俱乐部副主席和核心讲师，个人博客为 http://redmoon.cnblogs.com。现在他作为共同创始人经营着一家 环境保护技术公司。参与InfoQ中文站内容建设，请邮件至 china-editorial@infoq.com。