给Ajax技术初学者的一些建议

to winterwolf：
不是来压你，而是希望你在真正了解REST之前，不要贸然将自己的某种设计冠以REST。我们在充分讨论之前，其实需要对于要讨论的内容有一些共同的了解才行。否则可能你说你的，我说我的。你说的是winterwolf的观点，我说的是dlee的观点，其实都不是真正的REST。

请问dlee，这篇论文什么时候可以看到中文版呢？

明白了。 可能想起我过去提到的cocoon中间层了。 你不了解也是正常的。

这样吧等我把东西做完了 就将它开源出来。 到时候你来鉴定一下它是不是rest   

目前所有内容的初稿都已经翻译完成了。我们大约在下周三之前完成所有的校对和排版工作。然后发给国内的一些专家来做review，review的时间是两周。最后发给Fielding，由他来发布（因为是有版权的作品，即使是翻译，我们也不能任意发布）。

所以最后网友们看到这篇论文的中文版，应该是在6月中旬之前。

早买了AJAX in Action还一直没来得及看。。。

to dlee,robbin等REST支持者:


我不相信REST能优美地表述现实应用中各种各样的Ajax请求。

给你们下个战书:），用REST表达CMS（内容管理系统）中关于栏目（column,树型结构，每个栏目的管理权限是分开的）的一些操作，我已经用URL参数方式表达（这里只是表达功能，现实中我只用表单POST提交），你们可以把REST方式表达写在下面，大家比比看哪种表达更好。

1、新建栏目(fid是父栏目ID)
/cms/addColumn?fid=y&attr1=x1&attr2=x2...

2、删除某栏目下的N个子栏目
/cms/deleteColumn?id=y1&id=y2...

3、删除某栏目，连带其所有子孙栏目
/cms/deleteColumnWithSub?id=y

4、修改栏目属性
/cms/updateColumn?id=y&attr1=x1&attr2=x2...

5、取整个栏目树(某些UI界面需要列出所有的栏目)
/cms/getAllColumn

6、取某个栏目下的所有子栏目（管理界面的栏目树要动态加载子栏目节点）
/cms/getSubColumn?id=y

7、发布某个子栏目（对CMS，只有发布的栏目才可访问）
/cms/publishColumn?id=y

8、撤消某个子栏目（反发布）
/cms/disPublishColumn?id=y

9、将子栏目y从父栏目A1移动到父栏目A2
/cms/moveColumn?id=y&tfid=A2

10、将栏目y与栏目A合并
/cms/mergeColumn?id=y&tid=A

11、将栏目在兄弟栏目中的位置上移一位
/cms/moveColumnUp?id=y

12、将栏目在兄弟栏目中的位置下移一位
/cms/moveColumnDown?id=y

13、将栏目在兄弟栏目中的位置移到顶部
/cms/moveColumnTop?id=y

14、将栏目在兄弟栏目中的位置移到底部
/cms/moveColumnBottom?id=y

15、批量改变某栏目下所有子栏目的显示顺序（11-14功能的另一种实现方式）
/cms/reorderSubColumns?id=y1&order=x1&id=y2&order=x2...


就这些吧，其他还有版本化管理，模板管理，权限管理、数据导入导出等等，且都不论。


这些请求方法如果都能用REST方式完美表达，我们这些顽固的怀疑主义者也就没什么可说了，呵呵。

继续开谈。。。用HTTP/REST做Ajax后端是肯定是勉强的、不匹配的、混杂的。

为了便于深入讨论，下面几点上我们要建立共识：
--------------------------------------------

1、所有的服务（或Request、或Action、或Function、或Method、或Command）都可以抽象成资源+操作，需要一个名词和一个动词来表达。名词表达的资源有时是多个同类资源。

2、从调用者的角度看，服务可以用谓语动词+宾语名词来表达,即Operate（ObjectID/ObjectIDs，Paras）,面向过程的架构（如RPC/SQL/DOS和UNIX的命令）使用这种表达。

3、从服务提供者的角度看，服务可以用主语名词+谓语动词来表达，既Object.Operate(Paras),面向对象的架构（如SOAP[伪]/RMI/CORBA/EJB/DCOM）使用这种表达。

4、从面向对象语言普及以来，业界总想用面向对象方式表达服务，这种追求在进程内是成功的，但在进程间（或主机间）一直不是很成功，主要原因是性能和复杂性，还有一个几乎被忽视的重要原因是:面向对象语法存在天然缺陷：语法上的混杂性，即当操作涉及同类的多个对象时，为了实现一致的单一谓语接口，只能用面向过程的语法来解决，即Objects.Operate(ObjectIDs，Paras)。

5、还好，HTTP/FTP等传统Web协议对服务的表达是面向过程的，如 GET /index.html。

6、在传统基于“服务器动态页面”的Web应用中，服务（每个HTTP请求）的含义是混杂的，即要表达“资源+操作”，还要表达“返回一个界面视图”，而后者往往在逻辑上和前者没有必然关系。而Ajax Web应用中，服务回归了“资源+操作”的单纯本意。


HTTP/REST为什么不适合作为通用服务接口：
---------------------------------------

HTTP协议最初的设计本意是针对HTML/GIF/JPG等无结构的简单Web资源的增删改查，再加上缓存机制。GET/POST/PUT/DELETE（还有OPTIONS/HEAD/TRACE/CONNECT）等谓语动词对那些无结构的简单Web资源以及对这些资源所须的简单操作是匹配的，合适的。

但是现实系统的操作谓语何止千万，现实系统的资源结构是何等复杂，岂是这区区G/P/P/D四种元操作所能表达，如果硬要套用G/P/P/D，只能让服务操作演变成两层操作定义(或叫复合谓语)：第一层是G/P/P/D，第二层再分Action，这样把简单问题复杂化。

其次，这种以URI为中心的模式，和面向对象语法一样，也有一个天然缺陷：对N个资源做同一种操作时很别扭，只能利用谓语优先逻辑。

其实HTTP协议的本意也是谓语优先的，面向过程的。但是Fielding同志抓住URI不放，生硬地将其理解成面向对象的，这就是REST的由来。

当然Fielding同志的主观出发点是好的，是想充分利用HTTP协议的cache机制、无状态机制来解决Web应用的性能问题和服务器集群问题；但后来Fielding将REST无限上纲，将本来被当代Web应用彻底废弃的put/delete等覆满灰尘的东西都搬出来，想学SQL语言用四种基本操作来映射世间万物，想用四座大山、四项基本原则来约束广大开发者的思想自由，这就很不应该了。须知SQL的select/insert/update/delete都是原子操作，只对单表，单数据类型；而现实的Ajax请求基本上都是事务操作，在SQL中的对应物是存储过程，如果Web服务请求可以概括为CURD，那么存储过程的设计者脑子就有问题了。

 

辛辛苦苦半个月，灌了68桶水，总算有一颗星了。

协议         URI                                   解释
----------------------------------------------------------------------
POST       /columns                         新建栏目
DELETE     /columns/1/subcolumns/1          删除某栏目下面的某子栏目
DELETE     /columns/1/subcolumns            删除某栏目下面的某些子栏目
DELETE     /columns/1                       删除某栏目及其所有子栏目
PUT        /columns/1                       修改某栏目属性
GET        /columns                         取所有栏目
GET        /columns/1/subcolumns            取某栏目的所有子栏目
PUT        /columns/1/subcolumns/1          发布某栏目的某子栏目
PUT        /columns/1/subcolumns/1          撤销某栏目的某子栏目
PUT        /columns/1/subcolumns/1          移动子栏目
PUT        /columns/1                       合并栏目，移动栏目，......
PUT        /columns/1/subcolumns            批量修改子栏目的显示顺序

REST到不是说URI不能带CGI参数，其实也可以带CGI参数的，REST的核心在于定义资源＋操作。凡是针对GET请求的request参数完全可以以?name=value方式传递，其他协议的参数不是在URI后面带的，是数据提交POST里面带的，不需要在URI上面标出来。

说到底，你还是不相信GET/POST/PUT/DELETE四种语义是完备的。这四种语义的完备性是REST理论的基础，要想证伪它的话，就要看你能不能提出有力的证据了。




没听说REST和面向对象有什么关系，这完全是你自己在臆测了，REST的理论基础是资源＋操作，而面向对象的理论基础是消息传递，完全两码事。

当然Fielding同志的主观出发点是好的，是想充分利用HTTP协议的cache机制、无状态机制来解决Web应用的性能问题和服务器集群问题；但后来Fielding将REST无限上纲，将本来被当代Web应用彻底废弃的put/delete等覆满灰尘的东西都搬出来，想学SQL语言用四种基本操作来映射世间万物，想用四座大山、四项基本原则来约束广大开发者的思想自由，这就很不应该了。须知SQL的select/insert/update/delete都是原子操作，只对单表，单数据类型；而现实的Ajax请求基本上都是事务操作，在SQL中的对应物是存储过程，如果Web服务请求可以概括为CURD，那么存储过程的设计者脑子就有问题了。

SQL也是同一个道理，针对资源(数据库表)的四种操作。恐怕不是存储过程设计者脑子有问题。是你的脑子太僵化了。