RESTful&Rails学习笔记(二)：资源的划分与命名

RESTful&Rails学习笔记(二)

REST风格web编程和传统web编程最大的不同就是HTTP方法的使用（这不是废话吗？地球人都知道啦）。

在rails里，资源对应到controller，就是说一个资源对应一个controller（心里YY一下：这样controller的数量岂不是会暴增?)，如果你把资源都划分好的话，controller就只有index(GET),new(GET),edit(GET),create(POST),show(GET),update(PUT),destrory(DELETE)七个方法。

关键就在于资源的划分和命名（URI），就拿用户注册，登陆来说，用户是一个资源，注意了，用户登陆系统，也是一个资源，我把它称之为登陆状态，尽量用名词来表示资源，不管资源是一个对象还是一种动作，因为这涉及到Rails的资源URL生成规则。拿面向对象设计来举例子，一个对象可以是一个资源，但一个操作也可以是一个资源，这就是最重要的区别。比如：

1. 传统的登陆，可能是这样的/users/login，对应UsersController#login方法，一般都是使用HTTP POST提交到服务器
2. RESTful登陆，/login_states，对应LoginStates#create，同样是用HTTP POST方法，为什么对应create方法呢？我认为用户登陆将是新增一个用户的登陆状态，当然注销就是销毁一个用户登陆状态。
3. 传统的注销，/users/logout，对应UsersController#logout，一般用的是HTTP GET方法
4. RESTful注销，/login_states，使用HTTP DELETE方法提交，对应LoginStates#destrory方法

区别甚大。

简单讲就是：对象是资源，操作也是资源。

对于资源的命名，应该尽量使用名词来命名资源，比如上面的登陆应该叫做LoginStates（登陆状态），而不是叫做Login(登陆），为什么呢？因为Rails会自动生成一个资源URL的辅助方法，其中有些要特别注意的地方：

1. login_states_path -> /login_states 如果是HTTP GET，对应index方法；如果是POST方法则对应create方法
2. login_state_path(:id) -> /login_states/:id

请注意上面两个方法的区别 1 比 2 多了一个"s"，因为Rails认为所有的资源，都是列表(list)和列表中的项(item)，没有第三种了，所以Rails默认的资源辅助方法的生成跟它的这种约定有很大的关系，尽量使用名词命名资源将会减少你的麻烦。

(请参考RESTful Web Service 中文版 173页，有很详细的说明）