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

这阵子正打算用Rails做个东东，所以开始系统地学习起了Rails。巧合的是，大概两周前，dlee邀请我加入Fielding博士关于REST的那篇论文的翻译团队。可以说Rails和REST这两个最热门的词汇几乎同时挤入了我的生活。随着我对Rails的学习和对[Fielding]的翻译，我也开始对REST产生了一些不太成熟的想法，写在这里与大家分享，同时也起到抛砖引玉的作用，欢迎大家讨论。

先复习一下REST的基本思想。[Fielding]把REST形式化地定义为一种架构风格（architecture style），它有架构元素（element）和架构约束（constraint）组成。这些概念比较晦涩难懂，而且我们做工程的往往并不需要形而上的理解。我们只知道，REST是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST提出了一些设计概念和准则：

1. 网络上的所有事物都被抽象为资源（resource）；
2. 每个资源对应一个唯一的资源标识（resource identifier）；
3. 通过通用的连接器接口（generic connector interface）对资源进行操作；
4. 对资源的各种操作不会改变资源标识；
5. 所有的操作都是无状态的（stateless）。

对于当今最常见的网络应用来说，resource identifier是url，generic connector interface是HTTP，第4条准则就是我们常说的url不变性。这些概念中的resouce最容易使人产生误解。resouce所指的并不是数据，而是数据+特定的表现形式（representation），这也是为什么REST的全名是Representational State Transfer的原因。举个例子来说，“本月卖得最好的10本书”和“你最喜欢的10本书”在数据上可能有重叠（有一本书即卖得好，你又喜欢），甚至完全相同。但是它们的representation不同，因此是不同的resource。

REST之所以能够简化开发，是因为其引入的架构约束，比如Rails 1.2中对REST的实现默认把controller中的方法限制在7个：index、show、new、edit、create、update和destory，这实际上就是对CURD的实现。更进一步讲，Rails（也是当今大部分网络应用）使用HTTP作为generic connector interface，HTTP则把对一个url的操作限制在了4个之内：GET、POST、PUT和DELETE。

REST之所以能够提高系统的可伸缩性，是因为它强制所有操作都是stateless的，这样就没有context的约束，如果要做分布式、做集群，就不需要考虑context的问题了。同时，它令系统可以有效地使用pool。REST对性能的另一个提升来自其对client和server任务的分配：server只负责提供resource以及操作resource的服务，而client要根据resource中的data和representation自己做render。这就减少了服务器的开销。

既然REST有这样的好处，那我们应该义无反顾地拥抱它啊！目前一些大牛（像DHH）都已经开始投入到了REST的世界，那我们这些人应该做什么或者说思考写什么你呢？我觉得我们应该思考两个问题：

1. 如何使用REST；
2. REST和MVC的关系。

第一个问题假设REST是我们应该采用的架构，然后讨论如何使用；第二个问题则要说明REST和当前最普遍应用的MVC是什么关系，互补还是取代？

我们先来谈谈第一个问题，如何使用REST。我感觉，REST除了给我们带来了一个崭新的架构以外，还有一个重要的贡献是在开发系统过程中的一种新的思维方式：通过url来设计系统的结构。根据REST，每个url都代表一个resource，而整个系统就是由这些resource组成的。因此，如果url是设计良好的，那么系统的结构就也应该是设计良好的。对于非高手级的开发人员来说，考虑一个系统如何架构总是一个很抽象的问题。敏捷开发所提倡的Test Driven Development，其好处之一（我觉得是最大的好处）就是可以通过testcase直观地设计系统的接口。比如在还没有创建一个class的时候就编写一个testcase，虽然设置不能通过编译，但是testcase中的方法调用可以很好地从class使用者的角度反映出需要的接口，从而为class的设计提供了直观的表现。这与在REST架构中通过url设计系统结构非常类似。虽然我们连一个功能都没有实现，但是我们可以先设计出我们认为合理的url，这些url甚至不能连接到任何page或action，但是它们直观地告诉我们：系统对用户的访问接口就应该是这样。根据这些url，我们可以很方便地设计系统的结构。

让我在这里重申一遍：REST允许我们通过url设计系统，就像Test Driven Development允许我们使用testcase设计class接口一样。

OK，既然url有这样的好处，那我们就着重讨论一下如何设计url。网络应用通常都是有hierarchy的，像棵大树。我们通常希望url也能反映出资源的层次性。比如对于一个blog应用：/articles表示所有的文章，/articles/1表示id为1的文章，这都比较直观。遗憾的是，网络应用的资源结构永远不会如此简单。因此人们常常会问这样一个问题：RESTful的url能覆盖所有的用户请求吗？比如，login如何RESTful？search如何RESTful？

从REST的概念上来看，所有可以被抽象为资源的东东都可以使用RESTful的url。因此对于上面的两个问题，如果login和search可以被抽象为资源，那么就可以使用RESTful的url。search比较简单，因为它会返回搜索结果，因此可以被抽象为资源，并且只实现index方法就可以了（只需要显示搜索结果，没有create、destory之类的东西）。然而这里面也有一个问题：search的关键字如何传给server？index方法显然应该使用HTTP GET，这会把关键字加到url后面，当然不符合REST的风格。要解决这个问题，可以把每次search看作一个资源，因此要创建create和index方法，create用来在用户点击“搜索”按钮是通过HTTP POST把关键字传给server，然后index则用来显示搜索结果。这样一来，我们还可以记录用户的搜索历史。使用同样的方法，我们也可以对login应用REST，即每次login动作是一个资源。

现在，我们来复杂一些的东东。如何用url表达“category为ruby的article”？一开始可能想到的是/category/ruby/articles，这种想法很直观。但是我觉得里面的category是不需要的，我们可以直接把“/ruby”理解为“category是ruby”，也就是说“ruby”出现的位置说明了它指的就是category。OK，/ruby/articles，单单从这个url上看，我们能获得多少关于category的信息呢？显然category隐藏在了url后面，这样做到底好不好，应该是仁者见仁，智者见智了。对于如何表达category这样的东西，我还没想出很好的方式，大家有什么好idea，可以一起讨论。

另外还有一种url形式，它对应到程序中的继承关系。比如product是一个父类，book和computer是其子类。那么所有产品的url应该是/products，所有书籍的url应该是/books，所有电脑的url应该是/computers。这一想法就比较直观了，而且再次验证了url可以帮助我们进行设计的论点。

让我再说明一下我的想法：如果每个用户需求都可以抽象为资源，那么就可以完全使用REST。

由此看来，使用REST的关键是如何抽象资源，抽象得越精确，对REST的应用就越好。因此，如何改变我们目前根深蒂固的基于action的思想是最重要的。

有了对第一个问题的讨论，第二个问题就容易讨论多了。REST会取代MVC吗？还是彼此是互补关系（就像AOP对于OOP）？答案是It depends！如果我们可以把所有的用户需求都可以抽象为资源，那么MVC就可以推出历史的舞台了。如果情况相反，那么我们就需要混合使用REST和MVC。

当然，这是非常理想的论断。可能我们无法找到一种方法可以把所有的用户需求都抽象为资源，因为保证这种抽象的完整性（即真的是所有需求都可以）需要形式化的证明。而且即使被证明出来了，由于开发人员的能力和喜好不同，MVC肯定也会成为不少人的首选。但是对于希望拥抱REST的人来说，这些都没有关系。只要你开发的系统所设计的问题域可以被合理地抽象为资源，那么REST就会成为你的开发利器。

所以，所有希望拥抱REST的朋友们，赶快训练自己如何带上资源的眼镜看世界吧，这才是REST的核心所在。

评论

60 楼 jinweijie 2007-06-13  

dennis_zane 写道

AllenYoung 写道

dennis_zane 写道

REST与Ajax的结合也是个很吸引人的话题，试想由RESTful的服务端API与客户端的ajax技术的相互调用，能够产生什么样的场景？很想听听大牛的看法。

目前我还想想不出REST加Ajax会产生什么样令人震撼的场景。REST的核心是resource，而我觉得对resource的操作最后肯定是通过传统HTTP请求发送到server端的。比如写一篇blog文章，无论如何利用Ajax，最后应该用传统的HTTP POST请求发送到server以便保存。

REST和Ajax的一个比较有趣的关系是，Ajax也许可以帮助我们解决resource难以建模的问题。就像我说过的那样，对名词的抽象很直观，但是动词就比较难办。而Ajax正好可以用来处理这些动词，同时保证url不变。当然，如何使用Ajax处理这些动词也是一个可以讨论的话题，我这里只是说有这个可能性。不过话说回来，即便使用Ajax处理动词的话，如何设计Ajax请求所发送到的url仍然是一个问题。目前来看，最可能的设计还是MVC形式的。所以一个可能的测量是：对所有名词使用REST架构，对动词尽量使用Ajax实现的MVC。这样至少可以保证url看起来是RESTful的。

我对REST中资源的理解，资源也可以看成是数据，我们对服务端的操作不外乎查询数据、增加数据等CRUD操作，而AJAX对服务端带来的改变是：服务端交给浏览器的不是内容，而将是数据。由javascript去扮演传统MVC框架中C的角色，负责数据的呈现、流程的转发和跳转。robbin说过，REST可能带来的是action的重用，我觉的很有道理，例如对应于用户加入圈子这个操作，对于管理员和申请者来说这个操作本质的工作是一样的——操作User这个资源，而成功后呈现的页面或者说结果不同，传统的MVC我们是写不同的action。现在，使用RESTful风格的服务端API来做，将只有一个传统意义上的action，而最终数据的呈现可以交给javascript。说着说着我自己都觉的不是很清晰：）

由javascript去扮演传统MVC框架中C的角色是不是风险太大了一点？毕竟是客户端的

59 楼 vannel 2007-06-07  

引用

将url的参数放到那里 ? !

www.findfood.com?a=1&b=2

可以变成 post www.findfood.com
<info>
<data>
........
</data>
<param>
<a>1</a>
<b>2</b>
</param>
</info>

我刚刚基础REST,按我的理解,如果是足够RESTful的设计，www.findfood.com?a=1&b=2这种URL，根本不会出现，也不需要考虑了，如果是根据a和b属性进行的查询的话，应该能通过a和b查到一个或一些符合条件的资源，相应的资源会有相应的ID，到最后，还是应该到了www.findfood.com/objects/search/list或者www.findfood.com/objects/99/吧。

58 楼 zzeric 2007-06-07  

winterwolf 写道

将url的参数放到那里 ? !

www.findfood.com?a=1&b=2

可以变成 post www.findfood.com
<info>
<data>
........
</data>
<param>
<a>1</a>
<b>2</b>
</param>
</info>

你这是算简化了还是复杂了？后台还得解析一把你的XML？还是要用XQuery去处理？

没看出这样用REST有啥好处

57 楼 blueoxygen 2007-06-03  

robbin 写道

通过URL来设计系统，这绝对是一个令人感到新鲜有趣的话题，很棒的分析，我很喜欢。

目前RoR的REST实现实际上就是REST和MVC混合方式，从实际开发角度来说，正如作者所言，很多情况难以进行资源的抽象。不过，即便如此，已经足够有革命性的意义了。

是否讲LZ的面向URL设计系统理解为，面向RESTful的资源来设计系统呢？

56 楼 blueoxygen 2007-06-03  

winterwolf 写道

ajoo 写道

我本身不了解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设计一个库，但是不许给任何方法带参数，我只怕做不到阿。

将url的参数放到那里 ? !

www.findfood.com?a=1&b=2

可以变成 post www.findfood.com
<info>
<data>
........
</data>
<param>
<a>1</a>
<b>2</b>
</param>
</info>

ajoo说的不是放哪里的问题吧。 你这个不是还是对资源额外附加了参数？

55 楼 blueoxygen 2007-06-03  

agile_boy 写道

就我的理解来看，REST是否只是适合于WEB开发，对应以前传统的C/S或者WebService接口是否有参考价值呢？
在我看来，开发的趋势应该是更容易抽象理解，更符合一般人的思维方式才好

引用

Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.

54 楼 whisper 2007-05-07  

REST其实就是Web-RPC
形式上url的foo/bar对应着bar方法，foo也就是那个隐藏的this，/signin表现为static
参数作为querystring或者post中的内容出现
换句话说，REST就是一个形式方法，他使得的url一一对应了一个函数，也就是说REST本身一个泛函，REST(url)=function
这样也就得到了 m(f)=g 的形式，REST是M空间中的一个泛函，RPC也是，直接函数调用就相当于一个不动点，有m(f)=f的形式

53 楼 qiezi 2007-04-18  

如果所有对象及操作都能分割成标准的7种操作的资源，那已经是RESTful了，剩下的东西我用rails和用cgi区别不大，都可以用模板方式批量生产。

REST没有解决的问题是如何把现有的东西分割成这种RESTful的资源，它只提出了一个目标，没有提出分割标准，实际上也不大可能把这个操作标准化，而这就是软件系统最复杂的部分，所以还是需要一个非常厉害的分析员来做这个工作。

直到有一天我们造出了一个系统，把各种模型及操作输入进去，它就自动完成RESTful的分割，那么所有工作就可以完全由机器做了。程序员还要做什么？界面已经由美工做了，他们只需要很简单地把RESTful连接到界面上就行。。或者程序员还剩下的工作就是“把各种模型及操作输入进去”，如果这个系统友好一点智能一点，我们的客户就可以干这个了。

52 楼 winterwolf 2007-04-17  

ajoo 写道

我本身不了解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设计一个库，但是不许给任何方法带参数，我只怕做不到阿。

将url的参数放到那里 ? !

www.findfood.com?a=1&b=2

可以变成 post www.findfood.com
<info>
<data>
........
</data>
<param>
<a>1</a>
<b>2</b>
</param>
</info>

51 楼 ozzzzzz 2007-04-17  

robbin 写道

这个讨论到后面已经走题了，也许每个人对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了。

本身我认为在ruby这个范围内讨论REST就不合适，而且在RAILS下更加不合适——我们现在只能说RAILS支持REST变成，不能说REST是RAILS的基础风格之一。实际上就文件组织形式来说zope更加类似REST的要求，RAILS在这个方面还差了十万八千里。同时更加让人觉得重要的是使用REST风格将给大家带来的业务分析层面的变化，这个需要单独讨论。
另外ajoo提的问题很切中要害，实际上这也牵涉到了RAILS这些快速的快速框架的基础构造的核心部分——Route组件的问题。而我们是否有理由利用这个技术去实现REST，目前我还在考虑。
总之REST风格有太多的新元素在里面，这个需要我们展开一个全方位的多角度的讨论，这么一篇贴是肯定容纳不下的。我想这个帖子主要还是用来说明究竟什么是REST，什么不是REST。

50 楼 weiqingfei 2007-04-17  

robbin 写道

这个讨论到后面已经走题了，也许每个人对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协议，用隐藏域来定义操作的。

49 楼 robbin 2007-04-17  

这个讨论到后面已经走题了，也许每个人对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了。

48 楼 robbin 2007-04-17  

ajoo 写道

我本身不了解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允许对资源的操作带有额外的参数，就意味着对同一个资源施加的一个操作不能够唯一确定资源的状态，那么就无法做到服务器端的无状态，从而各种对服务器端的前端缓存操作就无法实现了。

47 楼 ajoo 2007-04-17  

我本身不了解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设计一个库，但是不许给任何方法带参数，我只怕做不到阿。

46 楼 秦朝古月 2007-04-17  

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

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

45 楼 weiqingfei 2007-04-17  

winterwolf 写道

weiqingfei 写道

winterwolf 写道

weiqingfei 写道

大家能不能讨论以下rest的安全性问题。

如果rest想用ajax直接来调用web service安全性肯定有问题. ws不是单一的服务器端调用 往往需要将一个ws的输出加工发向第2个ws进行处理, 如此如此. 将所有ws需要的密码都传到客户端是可怕的.

在性能上ajax也会出问题 js用到现在已经超复合了 越来越难维护.

rest只是一种理论 完全按理论来肯定不行.

我想有一个办法能解决所有的问题 那就是添加一个中间层次 ajax->ws 变为 ajax->中间层->ws

中间层将数据加工认证后发给ws 同时为ajax提供view减轻ajax端的负担.

就REST本身来讲，脱离了ajax，就没有了什么意义，因为浏览器本身是不支持put delete的，
如果只谈它的理论的话，我想这个早就在做了，比如url的重定向，可以实现面向资源的操作。

ajax不可能一直保留着用户名密码传来传去，应该还是用cookie的方式保持sessionid，但是这样又违背了”服务器无状态“这句话。

我想安全性问题还是在应用REST时比较头痛的问题。

中间层也就是现在传统的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的话，就使得各个方面都是轻量级的了。

44 楼 winterwolf 2007-04-15  

weiqingfei 写道

winterwolf 写道

weiqingfei 写道

大家能不能讨论以下rest的安全性问题。

如果rest想用ajax直接来调用web service安全性肯定有问题. ws不是单一的服务器端调用 往往需要将一个ws的输出加工发向第2个ws进行处理, 如此如此. 将所有ws需要的密码都传到客户端是可怕的.

在性能上ajax也会出问题 js用到现在已经超复合了 越来越难维护.

rest只是一种理论 完全按理论来肯定不行.

我想有一个办法能解决所有的问题 那就是添加一个中间层次 ajax->ws 变为 ajax->中间层->ws

中间层将数据加工认证后发给ws 同时为ajax提供view减轻ajax端的负担.

就REST本身来讲，脱离了ajax，就没有了什么意义，因为浏览器本身是不支持put delete的，
如果只谈它的理论的话，我想这个早就在做了，比如url的重定向，可以实现面向资源的操作。

ajax不可能一直保留着用户名密码传来传去，应该还是用cookie的方式保持sessionid，但是这样又违背了”服务器无状态“这句话。

我想安全性问题还是在应用REST时比较头痛的问题。

中间层也就是现在传统的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功能和结构.

43 楼 bouzouki 2007-04-15  

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.

42 楼 maweifeng 2007-04-14  

面向对象的时代前，大家说使用对象，以后软件就像搭积木，面向组件的时代，软件就用组件来搭建，后来，软件用Web服务搭建，后来，用REST。<br/>
<br/>
实际上，谁都不行，软件也从来都不是搭积木。<br/>
<br/>
<strong>myaniu 写道：</strong><br/>
<div class='quote_div'>
<p>       目前web上支持REST风格的应用还是比较少，当REST风格的应用多起来之后，REST的优势才会明显的显现出来，比如我想要一个OpenID登录认证，一个web方式的word，一个留言版，一个相册，一个投票器。。。不用自己做，只需使用提供相应REST接口的应用就可以了，那时整个web就是一个巨大的组件库，而REST使得使用、开发这些组件变成很容易<br/>
</p>
</div>

41 楼 myaniu 2007-04-14  

<p><font>REST之乱谈：<br/>
      本人也是一Rails爱好者，现在仍然有每天上至少三次rubyonrail网站的习惯。当然对于1.2新增的特性REST也是很关注。<br/>
      REST风格的rails程序没有写过。rails程序倒是写过一些。<br/>
      C++,java,c#等语言的开发中，很多时候，我们会使用某种组件。以达到快速开发的目的，有时我们也会自己开发一些组件，以便重用。在web环境中，还有组件可以用吗？答案当然是可以，目前采用比较多的方案也许是soap，web service之类的东西，我没有太多研究。soap等方案以我的理解来看，还在用传统的基于函数调用的思想，曾帮朋友写过一个简单的使用web service的程序，采用rails完成，我的感觉是对于web接口和web service接口，得写差不多两套东西。不便于使用。采用REST方案能够使web接口和其他应用系统程序使用的接口实现最大的保持一致。也就是说业务逻辑只写一边，却可以被多个系统（包括自生）调用。这也许就是楼主所说的： <br/>
       REST之所以能够简化开发，是因为其引入的架构约束，比如Rails 1.2中对REST的实现默认把control</font><font>ler中的方法限制在7个：index、show、new、edit、create、update和destory。<br/>
       也许是个不恰当的比喻，传统的web系统之间交换信息，就像CISC,而REST就像是RISC，而我们设计者就像是一个编译器，把程序（web应用）编译（设计）成RISC指令（使用很少的操作）。刚开始我们可能很难习惯这种方式。</font></p>
<p>       目前web上支持REST风格的应用还是比较少，当REST风格的应用多起来之后，REST的优势才会明显的显现出来，比如我想要一个OpenID登录认证，一个web方式的word，一个留言版，一个相册，一个投票器。。。不用自己做，只需使用提供相应REST接口的应用就可以了，那时整个web就是一个巨大的组件库，而REST使得使用、开发这些组件变成很容易</p>
<p>       对于某个应用来说，REST的优势并不明显，REST可以减少controller中的方法（action）数，几个action也许会共用一个REST资源，各个action对于同一资源的表现也许会不一样。</p>
<p>     当要开发一系列web应用，而这些应用之间要交换数据，互相调用的时候，REST才会显出威力来。 </p>
<p>      深夜，脑子昏沉的情况下完成次回帖，仅发表一下看法，也许有很多想错、写错了，还请见谅。</p>