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

我不精通webdav但我在用webdav而且发现它很强大（webdav不只支持4个动作） 。 我对webdav很有兴趣

卖弄这个词是什么意思 ？ 因为你比别人了解 所以其他人就不能谈论某某技术 只要谈到了就是卖弄 ？

我觉的你的态度真是有问题 。

置于说fd如何如何 我是回复hax的发言 在看了原文后也改掉了 没必要发这么大火吧  ？

我觉得对照dlee所摘录的这段话，comet真的非常接近于REST的反面。
1. 使用comet的目的一个是变相获得服务器端push的能力。而HTTP本身并非为此设计，所有的method都是客户端主动发起的，如何能表达服务器端主动的动作呢？服务器端push，并不能映射到任何可以用HTTP语义表达的事物，用户代理和中间组件也不能真正理解它。（顺便问一句，comet对于proxy会有什么影响捏？）他们看到的只是一个始终没有结束的GET响应。要理解它，需要对响应的方式进行理解。
2. 基于comet可以实现通讯协议，例如dlee告诉我们的bayeux。http在其中扮演的角色，只是transport而已，我没有在其中看到任何REST风格。

3. 不可否认，这样使用HTTP确实有实际的需求。除了穿透防火墙之外，享受BS的零部署也是非常大的原因。

dlee的回复不是针对你的。莫非lordaeron是你的马甲

REST 不是所有的基于 HTTP 的应用都可以使用的一种构架风格。

REST 这种构架风格可以被典型的应用于新闻咨询类网站、论坛、相册、Blog、在线视频等系统中，因为这类系统所存取得主要内容就是资源，这类资源可以被缓存，可以被重新组合，可以很方便直观的用 URL 来表示，可以很直观的用 HTTP 中的方法原语来描述对它的操作。

REST 这种构架风格不适用于在线游戏（如 hax 大大所说的麻将，其它的五子棋、围棋、扑克、或者砍人游戏也属此类），在线即时通讯，其它一些从 C/S 模式转为 B/S 模式的系统等。这类系统典型的特点是信息不能够或者说不应该被缓存，可以被重新组合的是接口而不是资源，交互的信息不是纯粹的资源，很难作为一个资源来用 URL 描述，施加在这些信息的操作无法用 HTTP 中的方法原语来很好的描述。

另外，还有一些复杂的系统，例如网上商城，它其中一部分内容属于资源，而另一部分不属于资源，因此这类系统可以被部分的设计为 REST 构架风格的，而不需要完全的 REST 风格。

我们没有必要为了 REST 而 REST，就像我们不应该为了 Ajax 而 Ajax 一样。我们应当首先看清它适合做什么，不适合做什么，然后再讨论在一个项目中是否采用它，或者那一部分采用它。否则技术就不再是帮你完成任务的工具，而会成为你完成任务的负累。

所以，Comet 有必要 REST 吗？

dlee说过俺英文不及格滴 lordaeron也不及格吗

正常的 proxy 都会有个数据写入(请求)和数据读出(响应)时间的限制，对于 comet 这种响应时间无限的连接，到超时就会自动强行断掉，如果系统设计时没有考虑到这一点，可能会影响系统的正常运行。另外，代理与实际的Web服务器之间保持连接是有代价的，那就是它所使用的端口数，所以，代理服务器一般是承受不了这种保持大量连接的应用的。

非常同意！实际上，许多 C/S 模式系统被转到 B/S 模式上来，主要看中的就是零部署这一点。

是啊，我也觉得，代理既要和服务器连，又要和client连，不撑死才怪哈。。。被断开也没用，因为comet会自动重连。所以，我杞人忧天一下：comet要是流行起来，是不是代理都要完蛋啊。。。

to hax：
Comet确实并不是REST主要考虑要支持的场景。REST主要支持的场景是什么？在论文的4.1小节“万维网应用领域的需求”中讲的比较清楚。
我同意你的意见，Comet确实超出了Fielding当初所设想的典型场景，也就是Comet与REST不相容的说法。就目前来说，Comet的需求还不是很普遍。这个观点我与你不同，可能是因为我们所做的开发类型差别很大。我们可以保持不同的观点，共同观察技术未来的发展方向。
HTTP设计的原意就是所有的请求都是由客户端发起，服务器响应，而且请求是短期的。为何要这样设计？因为这样设计服务器端的可伸缩性最好。这个问题早已得到了证明，我们无需再争论HTTP这样设计是否合理。Comet确实超越了HTTP设计的原意，这导致了它存在明显的服务器端可伸缩性问题，再次证明了REST的正确性和预见性（识别出架构不匹配的能力）。服务器端目前有各种work around，你可以看一下Jetty的方案，我贴过一篇文档，想必你已经仔细读过。

我不是很了解使用XHR如何来实现Comet，刚好可以在这里请教一下，麻烦你再进行一些解释。我目前看到过的解决方案，包括Pushlets、Buyeux，使用的都是script标签。这种方式的实现看来要比XHR的实现更简单。

我从来没有说过REST包治百病的话，只是很讨厌某些人故意曲解Fielding的原意，再去误导群众。当然不是所有的应用都应该将状态完全保存在客户端，例如，工作流类型的应用，需要跨越多个客户端、由多个人、在一段时间内完成，这些状态就应该保存在服务器端。

还有一个重大的误解我要在这里指出：我觉得Fielding所说的状态，指的应该是与某一个单独客户端相关的状态，明确地说，就是我们以前习惯于保存在session中的状态。你说的4人麻将的状态其实并不是Fielding所说的那种状态。你先告诉我，如果按照传统的方式来实现，4人麻将的状态在服务器端是要保存到每个客户端的session中吗？如果那样的话，这个状态是不是会有4个副本？我们不能把“状态”无限扩大，认为保存在服务器端的所有状态都是Fielding所说的那种状态。

出于安全考虑，当然可以将Fielding所说的那种特定的状态保存在服务器端。REST并不是禁止你做这个禁止你做那个，REST并不是孙悟空头上的紧箍咒，很多人这样理解REST是完全错误的。REST只是告诉你，如果尽可能遵循REST的架构约束，你可以获得很多利益。如果违反REST的架构约束，你就会付出一些代价。例如将状态保存在服务器端会损害服务器端的可伸缩性。这样做是否值得，需要由设计者本人来做权衡。如果服务器的并发访问量不是很大，那么这样做的代价完全可以承受。但是如果服务器的并发访问量非常巨大，这样做可能会造成严重的后果。其实我以前基于Web MVC框架做开发的时候，也是尽量不在session中保存东西的。session中保存的东西越多，做集群就越困难，服务器端的可伸缩性就越差。这些常识性的问题，一再在这里争论，是不是会显得很无聊？

你这个同志就是喜欢对号入座，我没有说你啊。
Lordaeron的英语显然不及格，连上面我贴的那么浅显的英文都能读错，凭空诬陷好人（WebDAV）的清白，如果再继续大言不惭实在是有些过分了。