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

用户似乎得操作20次，或者ajax执行20次。如果这样子的话，还是先不用的好。

DELETE  /orders

又想了一下，错不在Fielding同志，错在把REST抬出来套在Ajax脑袋上的同志。

Fielding是在2000年总结的REST，那时候ajax只是少数像老夫这样的怀疑论者才使用的技术，当时主流Web开发技术是各种“服务器动态页面”，REST的很多提法都是针对各种不规范的“XSP”程序，比如关于URI的资源唯一性问题，对“服务器动态页面”类型的应用，确实比较重要；但对与ajax请求来说，反正URI用户是看不见的，搜索引擎也是看不见的，HTTP缓存机制基本也是用不上的，这种情况下，死缠URI的规范严瑾还有什么意义？

to leebai：
我免战。可以先告一段落了，等过一段时间干完活了再来与你缠斗。:D

注意：REST是一种架构风格，RPC是另外一种架构风格。为何HTTP要设计为现在这个样子，大家最好先看了论文再来争论。
有一点是肯定的，如果你想要充分利用HTTP底层的基础设施，例如HTTP缓存、HTTP认证，并且使得你们的Web应用具有最佳的可伸缩性，那么最好基于REST的架构来做设计。为何REST风格的架构能够满足这样的可伸缩性要求，请自行去阅读论文，在论文中有相当严密的理论和实践方面的证明。如果连论文都不肯阅读，我真的没有多大兴趣去陪一个不肯学习接受新知识新观念（当然REST本身并不新，只是对于某些不了解的同学而言）的人版聊。纠正某些人的误解或者在这里做REST和HTTP的科普并不是我的责任，还有更加有利可图的事情等着我。

Fielding是何许人也？他是NCSA之外的第一个Web接口库libwww-perl的开发者，还是Apache HTTP服务器的核心设计者，早期Apache内部的所有与协议有关的部分都是他设计开发的，所以你们可别以为他就是一个成天喝茶看报的老学究。

上面的两位同学，我先闪人了。有本事你们去可以著书立说完全推翻Fielding的理论。只要你能写出来，我可以保证你绝对能出版。

你的错就是一向太喜欢主观臆测，当然有独立的思想是非常棒的。你继续这样臆测下去就不要怪我不陪你玩了。

不许吓唬人 。“臆测”都是我引题，背后都是有理性论述支持的，偶一般不喜欢空口白话瞎咋呼。

得了吧，我可以肯定地告诉你，你在诬蔑Fielding，人家的真正想法不是你说的这样的。

如果非要在一次web请求过程中，同时处理多项资源的多个操作，确实无法简单的映射到四种基本操作上。我看了一下beast项目，没有找到需要同时处理多项资源的场景。当然，在复杂一点的项目当中，确实存在这种需求，以目前我所知道的情况来说，我不知道有什么很优雅的解决方案。

如果我碰到这种情况，会在标准的GET/POST/PUT/DELETE之外，自定义其他语义操作，在该语义映射的action方法中处理这个请求。在这个方面，RoR的支持是很强大的，可以在routes.rb里面随意定义扩展操作语义，然后自动生成相关的link helper和action映射。当然，你可以说，在这种情况下，4个基本操作不是完备的。

继续版聊。说实话，偶确实没看过Fielding的论文，但看过一些REST的资料，据我对HTTP的理解，我看出REST是为了捍卫HTTP的纯洁性，这对2000年至今的“动态服务器页面”web应用确实很重要；但对于目前流行的ajax，其请后台请求部分（不是前台程序外壳部分）我的观点是：需要一个简化的Http协议来支持，我一直有个观点：刚好够用的东西，一定是最好用东西。

我已经更正我的说法了，错不在Fielding。这种大人物，得罪不起，呵呵。

又想了一下，错不在Fielding同志，错在把REST抬出来套在Ajax脑袋上的同志。

Fielding是在2000年总结的REST，那时候ajax只是少数像老夫这样的怀疑论者才使用的技术，当时主流Web开发技术是各种“服务器动态页面”，REST的很多提法都是针对各种不规范的“XSP”程序，比如关于URI的资源唯一性问题，对“服务器动态页面”类型的应用，确实比较重要；但对与ajax请求来说，反正URI用户是看不见的，搜索引擎也是看不见的，HTTP缓存机制基本也是用不上的，这种情况下，死缠URI的规范严瑾还有什么意义？

winterwolf应该理解我的意思。