REST 是什么？

开发过程中，在三个Model的REST描述上，我昨天冥思苦想了一整天。突然对REST有了顿悟，对于以前的错误理解捶胸顿足。

REST不是什么？

1. REST不是技术

  之所以说REST更接近道，是因为REST不是一种技术，而是一种思想，任何方式都可以实现。使用Rails 1.2不代表使用了REST。

2. REST不是Model的Proxy

  以为只要Model和Model的关系设计好了，REST风格的URL就被决定了。这就是我前段时间所犯的最愚蠢的错误。这种思想让我用Model First的方式设计系统。结果系统实现得越多，离用户价值越远。

3. REST不是 map.resources，更不是Nested Resource

  如果按照Model的层次关系来设计URL，如果层次关系很深，必然导致Nested Resource的层次很深。而是否需要这样的URL应该由需求决定，而不是Model。

这篇文章以及评论讲得非常好。Nested Resource的目的是向URI中加入以及解析必须的参数,而不是把Model的关系展现出来,更不是在URL上耍酷。

至于加入什么参数，完全是由需求决定。

4. REST不是Model的CRUD与Controller的绑定
假如我需要这样两个用户接口：

GET /:project_name/messages

某一个Project的所有Message

GET /:project_name/tags/:tag_name/messages

某一个Project的某一个tag的所有Messages
如果一定要按照常见的CRUD原则来作，这两个操作都应该访问Messages Controller的'index' Action，然后判断params里面是否有tag_name参数。这就是我犯过的愚蠢的错误。

class MessagesController < ApplicationController

  def index 
    if params[:tag_name]
      @messages = Message.find_by_tag_name_and_project(params[:tag_name], params[:project_name])
    else
      @messages = Message.find_by_project(params[:project_name])
    end
  end
end

         正确做法：

map.connect '/:project_name/tags/:tag_name/messages', :controller => 'tag_messages'

这个URL请求就会分发到TagMessages的 index. 这样作不会引入更多的Controller和Action么？没错！

class MessagesController < ApplicationController
  def index
    @messages = Message.find_by_project(params[:project_name])
  end
end

class TagMessagesController < ApplicationController

  def index
    @messages = Message.find_by_tag_name_and_project(params[:tag_name], params[:project_name])
  end

end

既然

/:project_name/messages

和

/:project_name/tags/:tag_name/messages

是两个不同的用户接口，为什么要放到一个Action里面？多个不同地请求在同一个action里面用if ... else if... 来判断好还是由各自的action执行好？

REST是什么？

REST体现了软件开发的最终目标：实现用户价值！实现用户价值的开发就要求我们从User Interface开始设计，而不是Model。

无论是BS还是CS架构，对于Server端来说，用户接口就是网络协议，比如HTTP。HTTP接口就是Web Server的User Interface，同时也是Client端的Service Interface。从HTTP接口开始设计Web架构就是REST思想。

HTTP接口是什么？URI，HTTP Method 以及Content-type, Accept-language等HTTP Header的一个集合就是一个HTTP接口。

对于HTTP接口来说，无论是View的代码怎么写，还是Controller和Model怎么实现都属于实现细节。从这点来讲，HTTP接口是系统中最稳定的User Interface。

MVC各个部分的实现也要从User Interface来实现，这些部分的User Interface是什么我还没想好。至少TDD的Test First就是一种User Interface First的体现。

REST与其他思想万法归宗，是一种道。请读者不要把本文当作文字或者概念，更不要对文字产生任何争论。真正的道纯属个人领悟，只要是文字描述出来的就不是道，执著于文字更是愚蠢至极。

说得挺好，有些启发

刚接触REST感觉这东西挺简单，越看越觉得复杂。

现在，反而感觉有点摸不到REST到底是什么啦 呵呵

继续学习……

看来真的什么都不能说了，呵呵

REST是一个概念，一种风格，是看不见也摸不着的东西，看看作者的陈述吧:

REST提供了一组架构约束，当作为一个整体来应用时，强调组件交互的可伸缩性、接口的通用性、组件的独立部署、以及用来减少交互延迟、增加安全性、封装遗留系统的中间件。
而REST架构约束包括客户-服务器、无状态、缓存、统一接口、分层系统、按需代码等。

由此可知，所有将REST应用于现代Web架构的设计都只是REST思想指导下的实践，比如Restful Rails，比如HTTP动词设计。

I like this point.

rest 就是无状态的http协议精神的延伸，不共享状态 所以能集群 大规模提高性能 和并发而没有副作用

我的理解比较简单，没有领悟到那么深入的东西。

原文在 http://www.dualface.com/blog/?p=356，太长了就不贴了。

我想REST的目的就是规范对资源的操作。
狭义上来说，资源一般就是数据库的资源。

所以，在REST中，一个URL就变得更加有意义：
/project/users
可以表示得到一个project下的所有用户。

而楼主所要表达的，只是对一个URL，如何用controller来
进行处理。

其实URL还是应该明显的表示出对资源的操作。

对这个尤其不能认同

何为“User Interface”？URL？
Rails 中的Model已经不仅仅是一个数据库的Model，而是业务和数据库的结合，是一个充血的模型。
理所当然我们应该从分析业务领域入手。

这里跑个题，很多人说Rails中是 业务代码写到controller里，其实是错误的，之所以会这么做，
是因为你的业务非常简单，其实业务代码是应该写到model里的。

看了还是不是非常理解。：（
是不是可以这么认为，REST是为了把一些东西规范起来，通过一些规范或设置把一些内容标准化、简单化？

第4点，通过map.connect来映射controller/action和URL，这个早在1.2之前就是这样的吧。