关于REST的一点想法，欢迎大家讨论。

REST之乱谈：
      本人也是一Rails爱好者，现在仍然有每天上至少三次rubyonrail网站的习惯。当然对于1.2新增的特性REST也是很关注。
      REST风格的rails程序没有写过。rails程序倒是写过一些。
      C++,java,c#等语言的开发中，很多时候，我们会使用某种组件。以达到快速开发的目的，有时我们也会自己开发一些组件，以便重用。在web环境中，还有组件可以用吗？答案当然是可以，目前采用比较多的方案也许是soap，web service之类的东西，我没有太多研究。soap等方案以我的理解来看，还在用传统的基于函数调用的思想，曾帮朋友写过一个简单的使用web service的程序，采用rails完成，我的感觉是对于web接口和web service接口，得写差不多两套东西。不便于使用。采用REST方案能够使web接口和其他应用系统程序使用的接口实现最大的保持一致。也就是说业务逻辑只写一边，却可以被多个系统（包括自生）调用。这也许就是楼主所说的：
       REST之所以能够简化开发，是因为其引入的架构约束，比如Rails 1.2中对REST的实现默认把controller中的方法限制在7个：index、show、new、edit、create、update和destory。
       也许是个不恰当的比喻，传统的web系统之间交换信息，就像CISC,而REST就像是RISC，而我们设计者就像是一个编译器，把程序（web应用）编译（设计）成RISC指令（使用很少的操作）。刚开始我们可能很难习惯这种方式。

       目前web上支持REST风格的应用还是比较少，当REST风格的应用多起来之后，REST的优势才会明显的显现出来，比如我想要一个OpenID登录认证，一个web方式的word，一个留言版，一个相册，一个投票器。。。不用自己做，只需使用提供相应REST接口的应用就可以了，那时整个web就是一个巨大的组件库，而REST使得使用、开发这些组件变成很容易

       对于某个应用来说，REST的优势并不明显，REST可以减少controller中的方法（action）数，几个action也许会共用一个REST资源，各个action对于同一资源的表现也许会不一样。

     当要开发一系列web应用，而这些应用之间要交换数据，互相调用的时候，REST才会显出威力来。

      深夜，脑子昏沉的情况下完成次回帖，仅发表一下看法，也许有很多想错、写错了，还请见谅。

面向对象的时代前，大家说使用对象，以后软件就像搭积木，面向组件的时代，软件就用组件来搭建，后来，软件用Web服务搭建，后来，用REST。

实际上，谁都不行，软件也从来都不是搭积木。

myaniu 写道：

IMO, REST is about styles of ARCHITECTURE & constraints on ELEMENTS, it benefits the so called Modern Web as a whole, not any single webapp.

A single webapp is NOT a ``Network-based Software'', the Modern Web is.

中间层也就是现在传统的webapp 通过它来调用web service然后加工成小片的view 提供给ajax.

好处有以下几点

1 ajax始终访问自己的安全域不会出现跨域的问题.

2 用户名可以保存在cookie或者session中.

3  用户和WS端根本不传递密码  WS和中间层的密码和权限对用户是完全不透明的

4 server端无须准备一整页的view来刷新 仅仅需要加工一小部分 比如<div id="xxx"/>中的ui元素提供给ajax. 从而减轻了server端的负载. 也符合rest的原理

5 ajax的代码减少了. 只用xmlhttp即可 复杂的ajax库就不需要了. 如果浏览器支持xform xul svg xmlhttp这类标准ajax的负担就更少了. 甚至少到ajax消失并变为新的js功能

6 WS和中间层间完全是无状态的  和rest打平. 由于中间层是server端 ws也是server端 无疑它们之间可以完成比rest更丰富的WS功能和结构.

奇怪，为什么要加个中间层呢，你这儿的ws指的是什么ws？传统的么？
你的rest表现在什么地方？ajax——》中间层，还是中间层-》ws？

传统的ws架构本来就是这个样子的，客户端-》服务器端-》ws，只不过客户端和服务器端传的是http，服务器端到ws传的是soap。

在我看来rest本来就是为了简化系统，而不是把系统搞复杂，用普通的bs架构就可以很好的应用rest，只不过客户端必须应用ajax来发送get，post，put，delete以及accept内容形式。
传输方面使用json的话，就使得各个方面都是轻量级的了。

我们目前的项目，是采用OpenID的认证方式。对于没有OpenID的用户，可以在我们自己的服务器上新建一个OpenID。

感觉REST主要针对的还是API。使用客户端，对于API的调用绝对可以做到真正的无状态。当然，每次调用都要传输密码。

我本身不了解rest。不过单单看这个帖子的表达，似乎觉得有点不对味。

先叙述一下我对这个文章的理解：
1。rest就是主语+谓语，主语就是resource，谓语就是动作
2。就象01是和机器说话的语言，obj.doSomething()是和javac说话的语言一样，resource/operation就是和web说话的语言。
3。在rest语言中，只有resource/operation，没有参数。


如果是这样，感觉上相当优美。只是，我的经验让我总不由自主地把resource/operation和obj.message()等同起来。两者间概念上是否相同呢？是否可以说rest语言就是一个dynamically typed的OO语言？是一个每个message都没有参数的语言？

可是，这样真的够用了么？一个纯粹的树形结构组织出来的语言真的足够表达我们在web上要做的所有事情么？
不错，我可以把tom.talkTo(Jack)变成session/tom/jack/talk，把add(a,b)变成addition/a/b/apply，不过这样做似乎有点自己做人肉编译器的感觉。:-)

别的我不知道，但是要我用ruby或者java设计一个库，但是不许给任何方法带参数，我只怕做不到阿。

REST和OO是不能够等同的。REST把唯一确定的URL作为资源，把针对URL不同访问方法(GET/POST，以及附加的其他参数)作为针对资源施加的操作。这个模型不OO，而且比OO要简单的多。

如果REST允许对资源的操作带有额外的参数，就意味着对同一个资源施加的一个操作不能够唯一确定资源的状态，那么就无法做到服务器端的无状态，从而各种对服务器端的前端缓存操作就无法实现了。

这个讨论到后面已经走题了，也许每个人对REST的理解都不同。

从rails框架对REST的支持角度来看，那么只要看一看beast项目的源代码，就可以很清楚的看出来rails对REST的理解。REST对于rails来说，毫无疑问减少了action的数量，看看beast的controllers，除了7个CRUD操作，自定义的额外的public的action很少。

对于rails框架来说，通过在POST协议之上附加额外的request参数，用来模拟PUT/DELETE，甚至各种其他自定义的操作，因此从这个角度来说，REST和AJAX没什么关系。从本质上来说，REST是简化互联网应用，提高互联网应用本身的伸缩性的，非要把AJAX扯进来，搞什么多层次结构转换，根本就是南辕北辙。

既然是ruby版的讨论，我就建议大家看看beast，Rick写的，rails框架作者之一，算是官方的rails REST demo了。

这个和在url后面跟加参数没有什么区别，说实话如果不是把操作放在请求头里，我看不出提出rest的意义，.net web里都是使用post协议，用隐藏域来定义操作的。