已经有无数人写过类似的内容，基本内容也都差不多，这次我写点少数人写过的。
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严格符合规则的好处是，程序接口统一，框架能够在这个统一的框架下提供更好的支持。
