BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Hartmut Wilms 关注 0 他的粉丝 ,译者 朱永光 关注 0 他的粉丝 发布于 2007年6月15日. 估计阅读时间: 6 分钟 | ArchSummit北京2018 共同探讨机器学习、信息安全、微服务治理的关键点

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 SnellJoe 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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT