关于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的核心所在。

评论

40 楼 weiqingfei 2007-04-13  

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时比较头痛的问题。

39 楼 Jamsa 2007-04-13  

REST是不是和以前Zope对资源处理的方式比较类似？如果是这样，那Zope处理资源的方式是不是更加成熟一些呢？

38 楼 winterwolf 2007-04-13  

weiqingfei 写道

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

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

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

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

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

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

37 楼 hideto 2007-04-13  

yuxie 写道

robbin以前说过REST能让代码减少到很少的程度（具体到多少忘了）。现在看来似乎有点言过其实。REST远没有想像中的那么强大。在我看来，如果采用纯REST架构的话，所谓的resource就是经过阉割的OO模型，只有属性，没有行为。为了表现这些被切掉的行为，我必须凭空再造出一个个所谓的resource来，切掉的行为越多，要造的就越多。这样的话，代码不可能有数量级的减少。再想一下，仅仅为了漂亮的URL，放弃自然和符合人类思维习惯的OO模型，这样真的值吗。套用T1同学的话来说：辛辛苦苦几十年，一夜回到了解放前。
所以我认为，REST只是在异构系统之间的webservice通讯上有优势，其他时候，还是该匝地匝地比较好。

我觉得Web应用很多地方都不适合OO，前台请求－》服务器处理－》返回结果不就是完全的面向过程的程序么？
REST拟或Rails开发真正有让我们眼前一亮的感觉。
套用搜狗的一句广告词：“REST更懂网络”

36 楼 agile_boy 2007-04-13  

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

35 楼 yuxie 2007-04-12  

AllenYoung 写道

yuxie 写道

能用ActiviRecord表示的东东使用REST很有前途
不能用ActiviRecord表示的东东使用REST很没前途

说白了是对于能够很直观地抽象为资源的东西REST比较合适。

yuxie 写道

我没有说ActiveRecord就是资源。我是说ActiveRecord可以让REST的代码大大简化。而对非ActiveRecord的资源，用不用REST代码量都差不多，可读性还变差，所以没有必要。

ActiveRecord本身就极大地简化了代码，无论你是用MVC、REST，甚至其它比较老的架构。

我不是这个意思。
关于REST在rails中的使用，大家一定看过dongbin同学的帖子
http://www.iteye.com/topic/38856
在这里，大家能很容易就能看出REST根本不省代码：

没有REST:16行 用了REST:21行

但是，如果我们能把这一块代码抽象出来，放到改进后的ActiveRevord基类中去，
代码就能减少很多：

class User < ActiveRecord::Base   
has_many :articles， :through => :unreadeds  
end  
  
class Article < ActiveRecord::Base   
has_many :users,:through => :unreadeds  
end  
  
class Unreaded < NewActiveRecord::Base   
end  

class UnreadedsController < ApplicationController   
scaffold_resource :product
end

结果就是：
没有REST:16行 用了REST:12行

但是呢，目前只有ActiveRecord适合这个抽象，像session对象这种东东，统统干不了这个活

34 楼 weiqingfei 2007-04-12  

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

33 楼 AllenYoung 2007-04-12  

yuxie 写道

能用ActiviRecord表示的东东使用REST很有前途
不能用ActiviRecord表示的东东使用REST很没前途

说白了是对于能够很直观地抽象为资源的东西REST比较合适。

yuxie 写道

我没有说ActiveRecord就是资源。我是说ActiveRecord可以让REST的代码大大简化。而对非ActiveRecord的资源，用不用REST代码量都差不多，可读性还变差，所以没有必要。

ActiveRecord本身就极大地简化了代码，无论你是用MVC、REST，甚至其它比较老的架构。

32 楼 AllenYoung 2007-04-12  

凤舞凰扬 写道

   对楼主的帖子有个小小疑问，也是自己没搞懂的。既然REST是Representation State Transfer，楼主又说所有操作都是无状态的，那么当中的State又是什么呢？
   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.
   从文字中理解， 每个选择的link都是一个state的改变。而点击link对于web系统来说，就是一种操作。看上去和楼主的无状态是矛盾的。
   大家有何想法？

REST提倡的stateless是指server是无状态的，也就是会所server不会保存与状态相关的信息（这当然是理想情况）。上面英文的大概意思是把网络应用看成一个有限状态机，那么对link的每次点击都会导致状态的跃迁，也就是state transition。Fielding的论文用的都是比较学术的词，看起来是比较麻烦。

Martin Flower的PEAA里面对状态这个东西（也就是session）的设计讲得很清楚。极少有网络应用不需要使用session，而HTTP是无状态的，所以问题就来了：在哪里保持session？Martin给出了三种方式：在client端、在server端和在database里。每种都有各自的优缺点。REST所谓的stateless，是说把session保持在client端，这样server就是stateless的。但是根据PEAA，这种做法也有trade-off，所以到底要怎么样，要看实际情况自己权衡。

31 楼 yuxie 2007-04-12  

dennis_zane 写道

yuxie 写道

gigix 写道

登录／注销：如果把“会话”看作资源，这两个操作就是“会话”资源的create和delete

大可以把这些代码抽象出来，以后根本不用generate就能使。可是rails目前没有这么做。

咳：
所以，写着写着，新的结论出来了
能用ActiviRecord表示的东东使用REST很有前途
不能用ActiviRecord表示的东东使用REST很没前途

你把资源狭义化了，资源 !=ActiveRecord
REST的资源更多的要求的是从资源去观察web操作，而并不是非要操纵ActiviRecord。REST是一种架构，更是一种思考方式

我没有说ActiveRecord就是资源。我是说ActiveRecord可以让REST的代码大大简化。而对非ActiveRecord的资源，用不用REST代码量都差不多，可读性还变差，所以没有必要。

30 楼 dennis_zane 2007-04-12  

yuxie 写道

gigix 写道

登录／注销：如果把“会话”看作资源，这两个操作就是“会话”资源的create和delete

大可以把这些代码抽象出来，以后根本不用generate就能使。可是rails目前没有这么做。

咳：
所以，写着写着，新的结论出来了
能用ActiviRecord表示的东东使用REST很有前途
不能用ActiviRecord表示的东东使用REST很没前途

你把资源狭义化了，资源 !=ActiveRecord
REST的资源更多的要求的是从资源去观察web操作，而并不是非要操纵ActiviRecord。REST是一种架构，更是一种思考方式

29 楼 yuxie 2007-04-12  

gigix 写道

登录／注销：如果把“会话”看作资源，这两个操作就是“会话”资源的create和delete

有道理。可是先不说这给代码可读性带来了什么坏处，这样的抽取，只能增加代码量，不能减少。因为除了原来user下的两个方法的内容拿到了userSession下，还得加一个userSession的类定义。

而大家所谓的能大大减少代码量的REST，应该是generate scaffold resource生成的那些代码。只要所有的resource都是那样的逻辑，比如：

 # GET /products
  # GET /products.xml
  def index
    @products = Product.find(:all)
    respond_to do |format|
      format.html # index.rhtml
      format.xml  { render :xml => @products.to_xml(:include => :categories) }
    end
  end

  # GET /products/1
  # GET /products/1.xml
  def show
    @product = Product.find(params[:id])

    respond_to do |format|
      format.html # show.rhtml
      format.xml  { render :xml => @product.to_xml }
    end
  end

  # GET /products/new
  def new
    @product = Product.new
  end

  # GET /products/1;edit
  def edit
    @product = Product.find(params[:id])
  end

  # POST /products
  # POST /products.xml
  def create
    @product = Product.new(params[:product])

    respond_to do |format|
      if @product.save
        flash[:notice] = 'Product was successfully created.'
        format.html { redirect_to product_url(@product) }
        format.xml  { head :created, :location => product_url(@product) }
      else
        format.html { render :action => "new" }
        format.xml  { render :xml => @product.errors.to_xml }
      end
    end
  end

  # PUT /products/1
  # PUT /products/1.xml
  def update
    @product = Product.find(params[:id])

    respond_to do |format|
      if @product.update_attributes(params[:product])
        flash[:notice] = '更新成功！'
        format.html { redirect_to product_url(@product) }
        format.xml  { head :ok }
      else
        format.html { render :action => "edit" }
        format.xml  { render :xml => @product.errors.to_xml }
      end
    end
  end

  # DELETE /products/1
  # DELETE /products/1.xml
  def destroy
    @product = Product.find(params[:id])
    @product.destroy

    respond_to do |format|
      format.html { redirect_to products_url }
      format.xml  { head :ok }
    end
  end

大可以把这些代码抽象出来，以后根本不用generate就能使。可是rails目前没有这么做。

咳：
所以，写着写着，新的结论出来了
能用ActiviRecord表示的东东使用REST很有前途
不能用ActiviRecord表示的东东使用REST很没前途

28 楼 weiqingfei 2007-04-12  

凤舞凰扬 写道

   对楼主的帖子有个小小疑问，也是自己没搞懂的。既然REST是Representation State Transfer，楼主又说所有操作都是无状态的，那么当中的State又是什么呢？
   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.
   从文字中理解， 每个选择的link都是一个state的改变。而点击link对于web系统来说，就是一种操作。看上去和楼主的无状态是矛盾的。
   大家有何想法？

无状态指的应该是“服务器无状态”。

27 楼 凤舞凰扬 2007-04-12  

   对楼主的帖子有个小小疑问，也是自己没搞懂的。既然REST是Representation State Transfer，楼主又说所有操作都是无状态的，那么当中的State又是什么呢？
   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.
   从文字中理解， 每个选择的link都是一个state的改变。而点击link对于web系统来说，就是一种操作。看上去和楼主的无状态是矛盾的。
   大家有何想法？

26 楼 dennis_zane 2007-04-12  

winterwolf 写道

其实实现rest是很容易的. 比如A+B...
rest post
***********
<info>
<A>234</A>
<B>678</B>
</info>
**************
to url---- ws.add

ws.add  运行xquery
******************************
let $doc := request:get-data()
let $A := $doc/A/text()
let $B := $doc/B/text()
let $C := $A + $B /*实际不能这么写*/
    return
   
<info>
{$A}+{$B}={$C}
</info>
****************************
将返回的信息交给ajax处理这样就是完整的rest

实现REST是不难，java的servlet一直就有put和delete方法，只是传统的MVC框架不重视，rails充分压榨了HTTP协议，在现有基础上的扩展远比重新定义一个复杂的规范易用得多。

25 楼 cvu 2007-04-12  

URL Orientated Design，好想法。以前一直不自觉地在用，AY的文章让我更清楚了。

有这么多名词，都很闪亮。FDD、TDD、BDD，到底应该由什么来驱动开发呢？我想他们针对不同的开发方面。简单的说就是
- Feature Driven Development，功能驱动整个开发流程，一段时间一个迭代。
- Behaviour Driven Design，虽然BDD从表面上看就是TDD的另一种写法，但是因为BDD是用用户的语言，是用来表述feature的，可以用来Design。BDD的产品是spec，有unit spec, functional spec, integration spec，这不就是设计书吗。
- URL Driven Modeling，AY的文章已经说的很清楚了
- Test Driven Coding，不用多说了。

24 楼 winterwolf 2007-04-12  

其实实现rest是很容易的. 比如A+B...
rest post
***********
<info>
<A>234</A>
<B>678</B>
</info>
**************
to url---- ws.add

ws.add  运行xquery
******************************
let $doc := request:get-data()
let $A := $doc/A/text()
let $B := $doc/B/text()
let $C := $A + $B /*实际不能这么写*/
    return
   
<info>
{$A}+{$B}={$C}
</info>
****************************
将返回的信息交给ajax处理这样就是完整的rest

23 楼 gigix 2007-04-12  

yuxie 写道

简单也得够用啊。没法直接用REST的实在太多了，比如登录，比如注销，比如计算两个人的薪水。我尝试想用REST来做个程序，遇到了太多的阻碍。

登录／注销：如果把“会话”看作资源，这两个操作就是“会话”资源的create和delete
“计算两个人的薪水”只是实现方式，也许你可以考虑它背后代表的业务价值是什么，你为什么需要计算这个东西，也许你会发现一个资源正好可以代表它
我并不是说REST可以处理所有情况，但它可以处理的情况也许比我们想象的要多

22 楼 AllenYoung 2007-04-12  

yuxie 写道

Rails的效率是实实在在摆在那里的，不写程序都能看出来，实际开发更是爽呆。而REST完全不能给人这种感觉。我也写了程序试了一下，具体的代码没数，但是肯定不是震撼级的减少。除非对Rails进行进一步的封装。目前generate出来的scaffold resource代码还是有很多重复性的。也许这个工作做好了REST会进一步发展。

scaffold_resource我也不太喜欢，不过我觉得这是Rails对REST的支持还不是很好。

yuxie 写道

简单也得够用啊。没法直接用REST的实在太多了，比如登录，比如注销，比如计算两个人的薪水。我尝试想用REST来做个程序，遇到了太多的阻碍。

确实是有问题，我从一开始就是说有些困难。但是这些困难是因为REST自身的局限，还是因为我们对它的理解和使用不成熟，这个是需要考虑的问题。

21 楼 yuxie 2007-04-12  

AllenYoung 写道

REST到底能把开发简化到什么程度，我看只有经过实际开发才能证明。就好像Rails刚出来的时候叫嚣开发效率比Java高10倍，我们也都嗤之以鼻。但是随着用过Rails的人多了，有经验的人也提出了比较中肯的提高程度，并且也被大家认可了。

Rails的效率是实实在在摆在那里的，不写程序都能看出来，实际开发更是爽呆。而REST完全不能给人这种感觉。我也写了程序试了一下，具体的代码没数，但是肯定不是震撼级的减少。除非对Rails进行进一步的封装。目前generate出来的scaffold resource代码还是有很多重复性的。也许这个工作做好了REST会进一步发展。

AllenYoung 写道

REST的优点就在于它很简单，而具体强大不强大，要看我们怎么使用。最好的东西不是最复杂最强大的，而是最简单最合适的。对REST的理解和运用程度直接影响着开发效率。这就好像OO很好，但是不是所有人都可以用好一样。

简单也得够用啊。没法直接用REST的实在太多了，比如登录，比如注销，比如计算两个人的薪水。我尝试想用REST来做个程序，遇到了太多的阻碍。