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

to robbin，谢谢纠正。你说的那些含义我都看过了，大部分懂了，但是还需要自己更多的实践来理解REST风格的URL能够表达的范围。

to winterwolf，我是就除GET方式之外的其他方式来说的。

REST把HTTP协议应用得非常充分啊，不过貌似离不开ajax这样可以remote call的工具。

你的设计有点意思，什么时候咱们专门开个主题深入讨论ajax服务接口的封装问题。

哈哈 误会啊。 我明白你的意思  不解释了

好啊  从现在的情况看怎么封装都可以 关键是server端能否明白和执行。不过我看w3c和大厂商会出标准的 也许现在已经有了 只是我不知道

HTTP请求给服务器的信息可以来自：
１方法，方法就那么几个，当然如果服务器是我们自己设计的，方法也可以扩充；
２URI
３URL参数
４请求头标
５body

在我看来，对ajax应用来说，与其让服务器从各个部分读取上行信息，不如简化协议（没简化协议之前，简化地使用协议），只保留从body读取信息，这样的架构应该是最简洁和健壮的。曾经发现SAP的j2ee服务器有个bug，cookie值中含有非URL允许的字符时，不能正确读取－－－如果服务器按我说的方式架构，就不会有这种问题。

javaeye好象公然违背这一规则啊？ 张三访问http://www.iteye.com/，返回“欢迎张三！”leebai访问http://www.iteye.com/，返回“欢迎leebai！”

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

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

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

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

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

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

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

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

winterwolf应该理解我的意思。

怪我没说清楚。我的意思不是删除所有某类资源，而是删除这类资源中的一部分。比如说总共1000个订单，用户想删除其中20个废单。我也想用rest，但我感觉rest风格下，代码似乎这样子：

DELETE /orders/1
DELETE /orders/2
DELETE /orders/3
...

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