RESTful&Rails学习笔记(三):在Rails下划分资源的小小经验

Rails支持RESTful,这个地球人都知道.在Rails认为两类的资源足以代表一切:列表和列表中的项.Rails默认的设计就是支持这两种类型的资源.

假设已经划分了了一个资源,那么在Rails里面就对应一个controller,model,view,MVC一个都不能少.当然也可以多个controller都使用同一个model,简而言之,就是一个资源对应一个Rails的controller,4个HTTP方法就对应controller里面的index,new,create,edit,update,show,destroy这7个方法.
举个例子:就拿一个blog来说事吧.
最近的blog是一个资源,对应BlogsController,查看blog列表对应的是index方法(HTTP GET),某一篇blog对应的是show(HTTP GET)方法.
那么,最受欢迎的blog按照RESTful资源的划分,也应该是一个资源.在Rails里面,也是对应一个controller么?比如叫做HotBlogsController.
如果我还有最多人收藏的blog,2008年撰写的blog......,按照Rails默认的风格,那岂不是要对应N个controller了?可以肯定地说,不用一会,你的controller就泛滥了.

刚开始的时候,我确定是这样做的,因为按RESTful的划分方法,最新的blog和最受欢迎的blog确实是两个资源,对于资源的表示,应该是用两个不同的URL来表示的.比如:/blogs表示最近的blog,/hotblogs表示最受欢迎的blog.
这个无可厚非的,这样的划分清楚明白,一看url就知道是啥东西了,符合当前web2.0的友好url的习惯,当然最重要的是用上一http的get方法,但并没有传统的那种rpc风格的url调用那样,后来来了一串的参数,尤其是这种:/blog?method=hot,/blog?method=recent...这本是好事,但放到rails里面,如果一个资源就对上一个controller的话,看着一堆的controller估计就是郁闷无比,而且这些资源只是一些条件不同而已,可能就是一个参数k=1,另外一个就是k=2的差别,就为了RESTful,我就得为了这个写上一个controller吗?
你接受得了吗?
估计现在RESTful还是不太流行,就是因为要遵守RESTful的约束和限制,按现在主流的开发思想来说是一件麻烦事吧.谁也不愿意为了k=1和k=2的差别就多写一个controller,就算RESTful吹上了天,还是不行!偶们都是干实事的人,不能为了RESTful而RESTful啊.

我用了一个折衷的方法解决此问题.
还是用上面的例子,最新的blog和最受欢迎的blog是两个不同的资源,但在Rails里面都对就同一个controller:BlogsController,两个不同的资源,当然有两个不同的资源表示,/blogs/recent就表示最新的blog,/blogs/hot就表示最受欢迎的blog.我只是在route.rb里做了一个小小和改动:

map.connect 'blogs/recent',:controller => 'blogs'               
map.connect 'blogs/hot',:controller => 'blogs'

这样做的好处就是不用为只是一个查询条件不同的资源又写一个controller,使用这种方法看似是在index方法里处理多个事情,不符合单一原则,其实不然,只要不过分,并且觉得好用,有什么是不可以的呢?

貌似比较简单,不过个问题着实困扰了我很久.相通此节,舒了一口气...