RESTful设计规则

已经有无数人写过类似的内容，基本内容也都差不多，这次我写点少数人写过的。

1. 基本规则：以资源为视角，固定操作方式

GET /books   #获取书目

GET /books/1  #获取某本书详情

GET /books/new  #显示添加新书的表单

POST /books  #添加新书

GET /books/1/edit  #显示编辑某本书的表单

PUT /books/1  #更新某本书

DELETE /books/1  #删除某本书

以上内容来自rails，也常常是大家写过无数遍的内容，对URL以资源的视角进行观察，每种资源都有其固定的URL模式，以模式映射对资源的固有操作方法。多数人的文章可能就收尾了，这个规则太简单，但现实世界更复杂一点，真实用户会碰上这个规则无法解决的冲突。

2. 子资源

子资源如同书和评论的类比，每本书都有自己的评论，评论作为一种资源从属于书。虽然可以把子资源提升为顶层资源，但肯定不是指的提倡的做法。

/books/1/comments

/books/1/comments/c1

子资源以 主资源+id+子资源+[子资源id] 的形式构造URL，以达到快速获取某主资源下子资源的目的。

3. 资源非标准行为

虽然标准的增删查改能覆盖绝大部分资源操作需求，但是总有一些时候，资源有特别的操作，或者是你想给资源的某个小操作赋予一个更有意义的名字，如对一本书进行 LIKE 操作。

把 LIKE 抽象成 likes 子资源是无意义的，这是一个操作行为，同时这个行为是针对用户资源而不是书这个资源。但我们可以把这个行为使用子资源的形式构建URL。

POST /books/1/like

这确实是参考了子资源的URL，能 work， 但是和子资源有语义冲突，我们应该想想更好的做法。

再从新想想非标准行为这个点：LIKE 是一个行为，可以抽象为一个资源，但是这个资源并不能归结成为子资源，但是如果是顶级资源的话，又不能算作纯粹的资源，如  /likes 这个顶级路径就很怪异。重要的是，他是和书相关的。

POST  /books/like/1

我们可以给这个顶级路径增加一个 namespace 来构建URL，既能区别于子资源模式，又能表达和书的相关性。

4. 资源子集操作行为

最后讲讲资源子集操作，实际上是某个顶级资源的集体对象的新的表现形式，或者批量修改操作。比如我想对图书资源再分别增加一个获取热门书目URL，一个搜索URL，类似这种获取资源子集的操作，应该怎么构建URL呢？

通过查询参数的方式来指定获取的资源子集，这有两个不足。第一，增加了controller的复杂性，里面的实现要 ifelse。第二，URL格式不好，我们就是想给URL起个好听一点的名字。

GET /books/hot

GET /books/search

这个模式其实不错，可读性和关联性都有了，但是有点和读取某本书详情的URL相冲突。

我觉得将子集查询抽象为新的只读资源可能更好，包括在controller的结构上。

GET /hot

GET /hot-books

GET /search

5. URL不是重点，重点是controller要完全符合第1条规则

我们不会在一个资源的controller上添加除了增删查改以外的任何方法，拿rails来讲也就是

index

show(id)

create

update(id)

delete(id)

所以当我想通过controller给资源增加非标准行为或者资源子集操作行为的时候，不管URL最后如何设计，我都会把这个行为抽象到一个新的controller中，让这个controller符合第1条规则。

controller严格符合规则的好处是，程序接口统一，框架能够在这个统一的框架下提供更好的支持。