“在webdav中的这种自定义method的方式，并不符合rest的原则。”——此言并不确切，fielding认可webdav的方法，restful也不限定method的数目。但，问题在于webdav自己定义的http方法可能会造成现有http支持设施的处理困难，因而出现实际应用中的问题。

也就是说，我上面的问题已经被回答了，方法不够用，那就：
A.增加方法，象 webdav 一样，但有底层设施不支持的问题(不好用)。
B.放到“社会主义初级阶段”的url里面去。但url显然会膨胀(不好看)。
这两种方法都是rest所接受的。

update2

状态有两种：连接的状态，资源的状态，二者并无直接的关联。rest考虑的是资源的状态，而极力避免连接的状态(这会在伸缩性上造成麻烦)，也就是“每次请求都是独立的(目前将其理解为，包含所有的必须信息)”，这意味着可以在任何另外一台web服务器上来处理这个请求，request本身包含处理这个请求的所需信息。而对于连接的状态，rest则旗帜鲜明的表示反对。一般而言将cookie或session都认为是不符合原则的。长连接的comet也在其列。

那么，现在的新问题是“有状态的连接”比如comet的chat应用，又要如何用rest的原则来指导其构建呢？

继续thinking…

刚才拉住dlee一阵猛问，很有收获，记载在下面。

“资源是一个抽象的概念，并非严格的必须是一个URL，如果操作不够，那就再构造几个新的URL来表达操作，把对于method的渴望映射到URL中。在webdav中的这种自定义method的方式，并不符合rest的原则。”

“rest的核心是操作语义的可见性，其目的是为了让应用有良好的可伸缩性。”

“http的无状态，也是从伸缩性角度的考虑。”

那么“从伸缩性的角度考虑，在rest指导下架构的应用，是否就必须是无状态的呢”或“在rest的框架内，如何处理有状态的应用？”又或者“有状态的应用如何映射为无状态的呢？”

继续思考……。

这些已经脱离了’资源’这个范畴了,算soa方面了,需要人肉写交互代码吧

CRUD 对于数据库应用当然是不错的抽象，但，现实应用中似乎并非只有数据库这一种应用。

比如：聊天室、竞价拍卖、股票交易……，这些隐含“有连接”概念(stateful)的应用。从实现层面，站在数据库的角度来看(如果是用数据库来实现的话)确实也可以说它有对实现数据库记录的 CRUD 动作(但假若我不是用数据库来实现的呢？)，显然这种抽象并非此类业务比较自然的抽象模型。以聊天为例，比如，可将其业务动词抽象为比较原始的：连接、发送、接收，若更复杂一些，还可以创造出 N 多种“业务动词”出来，这些和 CRUD 又该如何映射？

我的问题是：RESTful 规范只规定了4种动词(分别用4种 HTTP 方法来映射)，这4个动词是“严格规定” or “仅仅作为示例”？

“严格规定”意味着只能有这4个，因为 HTTP 1.1 的标准方法只支持8个方法，标准内的其他方法已有相对确定的含义，显然，前面已经说过，这在很多情况下都是不够用的。

“仅仅作为示例”则意味着，可以使用 HTTP 1.2 或更高版本比如 WebDav 规范之中定义过的方法，或者，用户也可以根据自己的业务需求自行定制新的 HTTP 方法，显然，这有导致 HTTP 方法大爆炸的危险，问题是，这些定制方法对于网络设备或者代理软件之类的也意味着难于处理的境地。