why REST?

此REST非彼rest, 不是让我们休息的，又一个buzzword, 不知道能蹦达几年？

fielding的论文让人昏昏欲睡，不如讨论一下。
1. 从开发上来说，那几个action用url参数一样可以标识，重要的是browser都不支持put/delete，调试费劲。web操作不要变种？
2. REST没有描述？ws可以从描述中生成包装类，直接调用访问即可。rest恐怕没这么幸运，返回格式未知。怎么让请求返回xml/json/html?
3. 效率和灵活性可能rest胜出，简单就灵活嘛。json更是rest的天然搭档
4. rest可以有通用包装, 这也是个优点：new Resource(url).delete();

欢迎大家从实践角度讨论一下～ 

没人理你。。我也一直没搞明白

个人觉得，rest就是在还原WWW、HTTP的初衷

同意drliujia

REST是为了肃清对HTTP的滥用，再次回到HTTP的本原上来，它不是WS的替代品，它是refined HTTP。
还有，我怎么不知道有的浏览器不支持PUT,DELETE，你把请求method指定成这个然后发送不就成了，就算服务器端不能识别，那你自己分析一下http header不一样吗。
记得在上学的时候老师就讲过有PUT,DELETE这几种方法，但是当时没人知道是干什么用的

1、HTML的表单提交只支持GET和POST，所以还是Ajax和REST配合得好一些，四种方法都支持；RIA和REST一起流行起来，不是偶然的。
2、《RESTful Web Services》里面介绍了一种描述：WADL。
3、REST可以借力WWW缓存，响应性能一流；对每种概念上的实体都有清晰的标识，随你怎么mashup。
4、统一的接口，想调别人的服务很简单，只要知道URL就够了。

其实光凭是HTTP设计者提出的架构思想和架构约束，就值得我们仔细研究和学着遵从了，除非我们不想用HTTP了。

我欣赏的REST好处：

• 美而恒定的URL
• 设计规范
• 资源分布优美
• 开发效率高(?)
• 调用简单
• SOA
• 统一接口
• 易mashup
• 多种表现形式
• 高响应性
• 低服务器要求
• 高可伸缩性

REST岂非rest乎？我想REST应该是Fielding同学久思之后的一次灵感闪现，惊奇地发现Web应用的世界竟然可以这么简单而巧妙地表述。

REST也有自己的适用范围，它的架构约束要求使用客户端/服务器之间的请求/响应机制，这样就不适合于P2P类型的应用了，也不适合于QQ那样的长连接的C/S应用，但也可以结合使用；它的服务器无状态性要求在服务器上避免使用session，会话状态全部保存在客户端，这样就对客户端提出了一定的要求，而且现在传统的Web应用几乎已离不开session了。

当然，REST是一种架构思想，我们可以只吸取其中对我们有用的部分，改进我们现有的架构设计，明白那些受到Web阻力的地方的原因。就像Rails对REST采取的策略一样。

我是因为REST才看上Ajax的，现在准备试一下WebC/S（决定叫这个了，大家一看就能明白），看清晰的职责划分能带来怎样美妙的代码。