Restful让我束手束脚

世说新语

浏览: 23511 次
性别:
来自: 北京

最近访客更多访客>>

zbz

classbt

whp121288

博主相关

博客

微博

相册

留言

关于我

文章分类

全部博客 (8)

社区版块

存档分类

Rails REST IE Ajax JavaScript

在Rails中View+Controller+Helper是紧耦合的，Controller中的方法与相关目录下的view template一一对应；Model+Migration+DB是紧耦合的。这2大块之间是松耦合的。

这2块的内部组织方式是完全不同的：

对于Model层，我们通常会对业务进行OO分析，提取出一些名词和名词之间的关系，然后把他们映射成Model，这个过程比较直观，是相对细粒度的。

对于View层，我们要考虑的是用户怎么用着舒服，为了用户的方便，页面可能很简单，也可能很复杂，一个页面可能包含多个Form，一个Controller也可能调用多个Model的功能对view提供支持，它是对Model的一个全新的组织，是相对粗粒度的。我们有可能把几个相互关联的Model组织到同一个View+Controller里面集中的向用户展示。

如果没有Restful，一切工作的很好，URL我爱怎么写就怎么写，全看个人习惯。但是现在Restful来了，一句 map.resources 给了我们7个URL。看看这个

map.resources :articles

问题是这句话假定我们有一个名为ArticlesController的控制器，这无形中把ArticlesController的功能限制为对某一项资源的CRUD。

想象一下这个场景，我要录入一篇Article，然后查询系统中已有的author（作者），把这篇artile与某个author关联起来。也就是在Add an article页面还要添加search author的功能，OK,问题来了，search_author这个方法我放哪？ArtilesController吗？你得自己添加map.connect，这似乎违反了restful，ArtilesController要处理另外一个资源的CRUD。AuthorsController吗？AuthorsController怎么关联到别的Controller的view? Controller是不是一定要和View一一对应？

我觉得应该是我对restful的理解还不够深入，但至少现在我觉得restful给我带来严重的限制。

查看图片附件

分享到：

为什么没有java on rails——代码量少才是 ... | 以Prototype为例说明现代的js用法（适用于 ...

2008-12-06 12:08
浏览 2337
评论(28)
论坛回复 / 浏览 (28 / 14897)
查看更多

28 楼 calmness 2008-12-22

Omnibus 写道

如果用概念，validation根本不該用POST。validation本身並不會改變object的狀態，你只要用get就可以。

用Rails角度看，你可以將validation換object來看，就不會有此困局。

GET /items/178/validation/SX00078

bencode 写道

偶问一个弱弱的问题，我在做一个购物网站，然后每个商品有一个编号，当然这个编号是不能重复的。然后我验证一个商品的时候，是不是差不多这样呀？

URL是：
/items/178/validate_sn
POST的数据可能是: sn: SX00078

这样可以吗？

因为 GET POST DELETE 都被我用光了，不够用了，如果不够用了该怎么办呢？

比如我还有一个批量添加商品的，我是这样组织的：

/items/batch_new // PS：暂时不管英语合不合理呀

因为“资源”，我可以用URL组织起来，但是四种操作往往不够用，这时候比较好的做好是怎么样的呢？

我有两种，不知道哪种更合理：

1. 就是上面的例子，把操作加到后面
2. 把操作加到 _method post 变量中，模拟 POST DELETE，

我现在是用了第一种，因为我发现也挺直观和方便的. 而且也和这样的URL统一

items/new
items/123/edit

谢谢大侠们指导

对于用户或者物品的验证，我们不应该将验证作为一个action，准确的说，可信任的用户或者商品本身就是一项资源，而实际对可信用户或者商品的验证的实质就是get可信用户或者商品，因此大致URL可以如下：
/user/auth/12345

如果无法获得12345这个可信的用户，那么实际就是证明该用户不可信任。
这里的重点是将可信用户作为一个资源抽象，这样我能过获得就是通过验证，无法获得就不是可信用户，而不是把验证作为一个action。

27 楼 Omnibus 2008-12-22

bencode 写道

26 楼 bencode 2008-12-20

25 楼 javatar 2008-12-15

Omnibus 写道

實作上，我比較愛將search都放入controller的index method之內，使用query string去分辨限制，就省去一route，亦符合REST GET的語意。

非常赞同，search是index的子集，URI应该定位在集合资源上。
像：

<form action="/authors" method="GET">
	<input type="text" name="keyword" />
	<input type="submit" />
</form>

或者：

/authors?keyword=xxx

有些人认为这样就不Restful了，
不知他们为什么这么讨厌URI中的那个问号，
好像Restful就是要把这个问号去掉似的，
这个问号本身就是URI协议的一部分，它是GET的状态语义。

24 楼 amonlei 2008-12-11

BirdGu 写道

我觉得很多人感觉restful“束手束脚”的原因就是把resource和model一一对应起来了。其实这是对restful的最大误解。

严重同意，资源应该跟响应的调用方（使用者）关联，毕竟rails不是纯净的rich client解决方案（纯净的就是后台传输数据，前台接受显示，flex就是如此，目前ajax还是会出现后台生成htmlorjs代码），so。。。。。。目前的resource是与view有点紧耦合的

23 楼下一站，火星 2008-12-10

BirdGu 写道

我觉得很多人感觉restful“束手束脚”的原因就是把resource和model一一对应起来了。其实这是对restful的最大误解。

我觉得restful的资源在rails应该理解为 1个页面+一个控制器+若干个model，和单个的model最多几毛钱的关系

22 楼 BirdGu 2008-12-10

我觉得很多人感觉restful“束手束脚”的原因就是把resource和model一一对应起来了。其实这是对restful的最大误解。

21 楼 ECyzl2007 2008-12-10

author作为article的一个属性，是属于one-to-many的关联关系，在录入一篇article的时候，应该有一个预装载author的动作（可以是通过遍历author资源来select，或者是search出唯一的author，当然如果该author不存在的情况需要在级联保存中save一个），然后在录入的方法里面级联保存，在Spring中SimpleFormController里的referenceData()就是作这个用的。

20 楼 Omnibus 2008-12-09

有否違反RESTful，本來就是學術上的問題嘛。REST只是統一接口。而HTTP下的四個method（GET/PUT/DELETE/POST），各有特定語意。一個resource配合四種操作，須按語意而行，不做令人意想不到之事。GET只是取出一項或多項resource，完全不會改變任何resource。PUT只是將一項resource覆寫。DELETE將一項resource刪去。上列三者，只要參數不變，無論執行一次或一千次，結果都是一樣。而POST，整體上會改變resource，在Rails就用來建立一項新resource。與其他method不同，執行一次創一項，一千次創一千項。

亦至於接口後的東西放在何處，悉隨尊便，不在REST/ROA之內。所以，不必有此擔心。

實作上，我比較愛將search都放入controller的index method之內，使用query string去分辨限制，就省去一route，亦符合REST GET的語意。

至於有說Search controller，除非我打算作一個跨越多個resource的search，否則都不必另立controller。

19 楼 liusong1111 2008-12-09

<div class='quote_title'>世说新语写道</div>
<div class='quote_div'>
<div class='quote_title'>gigix 写道</div>
<div class='quote_div'>
<div class='quote_title'>引用</div>
<div class='quote_div'>还是原来的例子，如果我们这样写map.resources :articles, :collection => {:search_by_author => :get}，那么URL会是这样的“/articles/search_by_author”，这个东西给IE用没问题，反正用户也不关心，他只关心看到的花花绿绿的页面。但如果有另外一个App要调用我们的服务来search author，他会非常困惑我查询一个author为什么url是这样的。从这个角度来讲search_author应该放在 AuthorsController当中。方法3）就是最好的，因为View和“Other App”是同等地位的Controller服务的使用者，View应该完全按照自己的逻辑进行组织，与Controller无关。</div>
 迷惑 你的问题是什么？ 不都是在建议你这么做吗？</div>
 
其实我一开始困惑的点主要是代码应该如何组织，大家都给了各自的建议，但意见并不统一，比如map.resources :articles, :collection => {:search_by_author => :get}就是liusong1111提出来的。而且对于为什么要这么组织说的不太详细。昨天下班前又翻了一下书，想明白了网站的用户除了IE还有“Other app”，IE可以用形如“/articles/search_by_author”的URL，而“Other app”不行。这才算彻底明白了。
应该说跟大家一起讨论和自己不断的通过书写来整理思路对理解问题是有好处的。
</div>
我开始以为你需要 /articles/search_by_author, 后来纠正了自己的错误,建议用 /authors/search. 这些基本功能,跟浏览器没多大关系.

18 楼 amonlei 2008-12-09

controller 要根据你的页面来定，而不是死板的定义为唯一不变的东东。比如你的author，其实分为给article这个页面用的，和独立自己管理用的两个资源

17 楼 hongkong 2008-12-09

resource 和 model 的关系，好比 model 和 function 的关系
说白了，就是业务职责的分配方式，粒度不同而已
当面向过程时，分析以function为焦点，面向对象则以object为焦点，function为补充
现在要面向资源，则以resource为焦点，model为补充
但MS没有以resource为焦点的框架，个人觉得rails还不够彻底。

16 楼 koalant 2008-12-09

yawl 写道

我有的时候在其他controller里添加个search action,有时候用个单独的SearchController。但也一直没觉得哪种更好些。

Search action 可以和 index action 合并为一个，这也是常用的做法，这样就不用再在 route 的 collection 中添加自定义的人 get 方法了

15 楼 yawl 2008-12-09

我有的时候在其他controller里添加个search action,有时候用个单独的SearchController。但也一直没觉得哪种更好些。

14 楼世说新语 2008-12-09

<div class='quote_title'>gigix 写道</div>
<div class='quote_div'>
<div class='quote_title'>引用</div>
<div class='quote_div'>还是原来的例子，如果我们这样写map.resources :articles, :collection => {:search_by_author => :get}，那么URL会是这样的“/articles/search_by_author”，这个东西给IE用没问题，反正用户也不关心，他只关心看到的花花绿绿的页面。但如果有另外一个App要调用我们的服务来search author，他会非常困惑我查询一个author为什么url是这样的。从这个角度来讲search_author应该放在 AuthorsController当中。方法3）就是最好的，因为View和“Other App”是同等地位的Controller服务的使用者，View应该完全按照自己的逻辑进行组织，与Controller无关。</div>
 迷惑 你的问题是什么？ 不都是在建议你这么做吗？</div>
 
其实我一开始困惑的点主要是代码应该如何组织，大家都给了各自的建议，但意见并不统一，比如map.resources :articles, :collection => {:search_by_author => :get}就是liusong1111提出来的。而且对于为什么要这么组织说的不太详细。昨天下班前又翻了一下书，想明白了网站的用户除了IE还有“Other app”，IE可以用形如“/articles/search_by_author”的URL，而“Other app”不行。这才算彻底明白了。
应该说跟大家一起讨论和自己不断的通过书写来整理思路对理解问题是有好处的。

13 楼 blackanger 2008-12-08

<restful web services> 这本书不错。

12 楼 gigix 2008-12-08

引用

还是原来的例子，如果我们这样写map.resources :articles, :collection => {:search_by_author => :get}，那么URL会是这样的“/articles/search_by_author”，这个东西给IE用没问题，反正用户也不关心，他只关心看到的花花绿绿的页面。但如果有另外一个App要调用我们的服务来search author，他会非常困惑我查询一个author为什么url是这样的。从这个角度来讲search_author应该放在 AuthorsController当中。方法3）就是最好的，因为View和“Other App”是同等地位的Controller服务的使用者，View应该完全按照自己的逻辑进行组织，与Controller无关。

迷惑
你的问题是什么？
不都是在建议你这么做吗？

11 楼世说新语 2008-12-08

假设的业务场景是这样的：客户需要进行文档电子化，需要录入文档，并把文档与DB中已有的人关联起来。
 
UI： 
页面左侧是document录入提交form，右侧是author的search form。右侧的search form是一个partial template（_search_authors.html.erb）。当用户点击搜索结果中某一项的radio 的时候会触发一个js,把该author的id和name拷贝到左侧docment form。 
 <img src='/upload/attachment/57485/ed35562d-ff3f-308c-ae15-c84286903938.jpg' alt=''/>
有3种代码的组织方式
1）search_authors 方法放在DocumentsController中
 Views/documents目录下包含_search_authors.html.erb和new.html.erb 
2）search_authors 方法放在AuthorsController中
 Views/documents目录下包含new.html.erb 
 View/authors目录下包含_search_authors.html.erb
3）search_authors 方法放在AuthorsController中
 Views/documents目录下包含_search_authors.html.erb和new.html.erb 
 
这3种组织方式究竟哪个好些，以什么为标准进行判断？如果没有定论，以上3中组织形式分别适用于什么情况？总不能到处乱放吧。
 
我个人倾向第一种，以javaEye的首页为例，这里包含推荐博客、焦点新闻、热门招聘、推荐圈子、javaeye黑板报等等等等10几项内容，如果按照方法2组织代码，View的局部模板要分散在10几个不同目录下。这显然是无法接受的。
 
如果方法1）的组织方式是较好的，我们在route.rb中应该这样写
map.resources :articles, :collection => {:search_by_author => :get}
但我认为这有问题，你可以这样map.resources :articles, :collection => {:recent => :get}来得到最新的文章，这里的recent是articles的子集，就是说它操作的资源依然是articles本身。而search_by_author操作的是另外一个资源author，我觉得这么用不合适。方法1）的组织方式和这种写法map.resources :articles, :collection => {:search_by_author => :get}倒地有没有违反restful?
 
 关于有同志建议用autocomplete功能，这个也想过，但是中国人名太短了，不太好做，你打一个“王”可能出来三四十个姓王的，先作罢了。
 
感谢楼上台湾/香港的朋友的回复，不过帖子学院气息稍重，我也去翻了一下《架构风格与基于网络的软件架构设计》这篇著名的文章，但说实话，真没看懂，现在的技术书籍多数通俗易懂，这种充满了术语又缺乏例子的博士论文看着真费劲。
让我们回到《Web开发敏捷之道》（第二版）（相信大家是人手一册了）P407
“REST化的应用程序无需操心如何实现可供其它应用程序访问的资源，它们只要为一组资源提供一个普通的（并且简单）的接口就行了。你的应用程序实现资源列举、创建、编辑和删除的方式，你的客户作剩下的事。” 
 <img src='/upload/attachment/57530/518b97a3-3c2b-32b1-82c6-9c00e5c68cc8.jpg' alt=''/>
我理解就是在编码的时候要时时想着你的URL/Controller不但是IE/View要用，所谓的“Other App”也要用，比如豆瓣调用卓越、当当的服务来进行价格比较。通过下面的代码
<pre name='code' class='ruby'>respond_to do |format|
 format.html # index.html.erb
 format.xml { render

ml => @authors }
end</pre>
我们可以做到，当IE发起请求时返回html，当“Other App”发起请求时返回xml或者别的什么.
 
还是原来的例子，如果我们这样写map.resources :articles, :collection => {:search_by_author => :get}，那么URL会是这样的“/articles/search_by_author”，这个东西给IE用没问题，反正用户也不关心，他只关心看到的花花绿绿的页面。但如果有另外一个App要调用我们的服务来search author，他会非常困惑我查询一个author为什么url是这样的。从这个角度来讲search_author应该放在AuthorsController当中。方法3）就是最好的，因为View和“Other App”是同等地位的Controller服务的使用者，View应该完全按照自己的逻辑进行组织，与Controller无关。View和Controller之间也是松耦合的，View（或者说已经发送到客户端被IE解析完了的View）调用Controller提供的服务。
 
 
 
又说了一大堆，不知道说的对不对。请大家共同讨论。

10 楼 Omnibus 2008-12-08

REST本身，並非是必要回單一個Model的資料，而不能有任組合資料。HTTP下REST最重要的目的，係每一次答回的資料，互相以uri及http method聯繫，讓資料由一個state跳去另一個state。所以合成資料，於REST本身係容許的。

HTML View只不過給browser（client）的劇本，敎他演譯如何由一個state跳去另一個state而已。

REST之上，人就創立Resource-oriented Architecture（ROA），定下原則如何為programmable web與人用的web共用同一種API，更符合HTTP protocol的原意。

programmable web，由於係給電腦程式使用，相比起人讀寫的資料及方法，要求內容格式及存取方法更一致，所以Rails就在ROA之上，訂下相關規則。主要劃分都是按資源項目來做，而資源的關係，如何附有額外資料，亦都建議視為資源。而實際資料如何顯示，並無限死單一形式。

以你的例，Resource來看，此處有Article與Author。Search亦不過交出Author的有條件的list。

你可以當browser與html是programmable web的舞臺，透過javascript去實現。Article Controller的new method，交html予browser做舞臺。用javascript取下author resource之list，用戶選後，javascript為Article添上author_id，最後用戶交上server造article之record。Browser在此角色，就兩個resource state的容器。

當然不愛用javascript，亦可以先由author入手，再將author_id資料交上article controller的new method，再由用戶填充確定造新record下。如此一來，browser每一頁都只不過是一個state，下一頁就是另一個state。

上面形式都是由一個state轉去另一個state，state與state之間，只係page內容儲下，轉state由uri及method實現，根本無違返REST之處。

9 楼 liusong1111 2008-12-08

细读了楼主的贴,发现问题很简单,foxgst和gigix说的很清楚.

首先,rails对REST的支持是在routes之上进行了简单的包装,跟传统MVC并不冲突. controller和model并没有绑定. 从rails的实现角度,一个资源指一个controller,跟model一点关系都没有.

搜索author列表这个功能,在创建article的页面里用到了,除去这个使用上下文,该功能在业务上是不是有独立性?我认为是有的. 放到AuthorsController里很正常,action取名为index/list/search/all都可以.

至于articles/new.rhtml中如何使用这个action,可以使用ajax+json的方式. 我以前发过个贴,说RJS对于REST是种反模式,我个人在任何时候都不主张使用RJS.

gigix是说,像google suggest那样,输入前几个字符时就自动弹出可选项,更人性化.

liuqiang是说抽象成Searchable, 比如你把author/article都用全文检索做了索引,这样抽象可能更容易组织代码,实现上稍微方便一些.

另外,你的例子很怪异,create article时还能选author. 正常应该从session里取吧

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论