APP对决Web3S:探索RESTful协议之路( 二 )


来自微软的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觬a对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中完全没有超链接的一般概念,无论是对外部数据的超链接,还是指向树中另一部分的超链接 。要遍历这些数据,你必须了解程序所采用的特定的数据定义 。

推荐阅读