Comet和REST是否有冲突？（兼REST辩论之观感）

这两天看了激烈讨论的帖子http://robbin.iteye.com/blog/82227，其中辩论双方都谈到Fielding的名言：HTTP不是Transport protocol（这个其实比较难理解的，主要是俺们英文差，不能区别Transfer和Transport的差别）。

抛开这个已经被锁定而无法继续回帖的帖子不谈，我就想到了Comet，按照我的理解，Comet就是利用HTTP来作Transport……而这样不是不符合REST了？

最后我再此谈一点对前面这个辩论的观感。偶本人对于分布式的理解是很浅薄的。但是我发现在后期的讨论中，其中一方因名责实。 其实Fielding同志作为HTTP的设计者之一，当然最有资格声明HTTP的设计意图。按照我的理解，HTTP只是他们（包括TBL等）对于整个Web架构设想的一环。因此REST论文，阐述的是整个对于web的世界观。因此他解说HTTP不是RPC，是从方法论层面来说的，如果偏要坚持说HTTP就是protocol level的东西，乃至载上tcp/udp包也可以，那就真的只能感叹“有点风马牛不相及”了。

comet有点象网络广播 fielding的意思可能是如果用http来comet会有性能问题 也就是说http不适合comet类的应用。

我感觉微软也许有能力放弃http

fielding同志没有评价过comet。。。那时候还没有comet这个名词(寒一个），他只是说http不是rpc，另外批评了一下webdav。

webdav我感觉很好 基于webdav一样可以restful .  fielding在论文里好像没有批判webdav

晕，你是上了那个大嘴巴Lordaeron的当了。

也别听另外一个大嘴巴winterwolf的。hax你自己完全有能力读懂Fielding的原意，Fielding论文的中文版已经放在那里了，我们可以凭良心说没有故意将自己的私货塞在里面。

to hax：
你看一下论文的5.1.7小节，Comet可以看作是按需代码的一种形式，它是REST的一种可选的约束。

6.5.3 HTTP is not a Transport Protocol
Most of the recently proposed extensions to HTTP, aside from WebDAV [60], have merely used HTTP as a way to move other application protocols through a firewall, which is a fundamentally misguided idea.

除WebDAV之外，近几年大多数对于HTTP的扩展建议，都仅仅把HTTP作为一种“搬运其他应用协议穿越防火墙”的手段，而这种概念从根本上是一种被误导的想法。

倒，被误导大了。。。我倒是扫了Fielding原文一下，就看到提到webdav了，咋没看出来意义完全相反捏。。。看来我要好好进修英文。。。

我现在粗略的看完了译文的前4章。。。

关于comet，你说是COD的一种，俺不能同意。按照我的理解，comet并非是下载代码对客户端进行扩展，而是可以push任何东西到客户端。因此它可以push代码，也可以push数据，或者消息，或者指令，或者事件。重要的问题是两点，第一是comet显然不太可能被缓存；第二是它可以用于持续的传递小粒度的数据。因此我觉得它似乎是transport，而不一定是transfer。因此我觉得comet是不符合REST的。

事实上，我感到一些web应用的需求也与REST之“分布式超媒体”的需求不同。例如一个web游戏，比如搓麻将，它是即时应用，它的计算部分很可能只能在server端完成，因此它既不是无状态，又不能缓存。当然，也许应该用其他方式（如Flash,applet）来编写游戏。。。但是我们确实应该可以用AJAX和comet来编写这样的web应用。

to hax：
这是一个很好的讨论话题。我的观点是这样的：
1. 首先，Comet类应用相对来说并不是一种非常普遍的场景，而是较为特殊的一种场景。REST是为Web应用常见的场景而优化过的，这些常见的场景并不包括Comet。
2. GET方法的请求默认情况下是要缓存的，但是不是说REST要求GET方法就必须要缓存。Comet这种情况是不需要缓存的。
3. GET方法的要求是它不应该改变服务器的状态。Comet也不会改变服务器的状态，它改变的是客户端的状态。
4. Comet从实现方式上来说，一般都是将服务器事件封装在一段script标签（就是一段可执行的JavaScript代码）中，客户端接收到之后立即执行。即使里面携带有数据，它还是一段可执行的代码，所以可以把它列为按需代码的一种。按需代码风格的问题是：

这个问题同样适用于Comet。与普通按需代码应用不同的是，Comet的一个请求永远不会结束。

至于你说的搓麻将的应用，它的计算一定要在服务器端完成，状态就一定要保存在服务器端吗？我觉得你的理解有些问题。很多年以前使用EJB的时候，尽管有Stateful Session Bean，但是绝大多数场合我们只使用Stateless Session Bean，其原因是类似的。

关于webdav rest原文中只提到上面一句子 没有批判webdav的意思啊？

http本身也应该修改 如果它不适合需求就应该被替换 而不应该让所有的人为了http而改变自己的需要 将自己都放进笼子里

webdav是一个很灵活的协议， 基于webdav也可以restful 而且相对http更灵活