RESTful是什么
REST（Representational State Transfe）是一种架构风格，遵循REST原则的架构我们就称为RESTful架构。Representational State Transfe 直译过来就是【表现层状态转化】，其实它省略了主语，表现层指的是【资源】的表现层，通俗的讲就是：资源在网络中以某种形式进行状态转移。
为什么要用RESTful
RESTful 给人的感觉是优雅、规范、易懂，一个结构清晰、易于理解的API完全可以省略许多无意义的沟通和文档。大家都使用相同的标准，有利于团队的整体效率。
接口设计
一般接口就是增删改查，RESTful API就像通用的模板，我们以文章（Article）举例，那么基础的URL就有一下几种：
GET /articles:文章列表GET /articles/id:文章详情POST /articles:创建文章PUT /articles/id:修改文章DELETE /articles/id:删除文章
RESTful 中使用GET、POST、PUT和DELETE来分别表示资源的查询、创建、更新和删除，并且除了POST其他三种都具备幂等性（多次请求效果相同），POST和PUT最大的区别就是幂等性，所以PUT也可以用于创建，只要在创建前就确定好资源的id。
将id放到URL中而不是Query Param的其中一个好处是可以表示资源之间的层级关系，例如文章下面会有评论（Comment）和点赞（Like），这两项资源必然会属于一篇文章，所以它们的URL应该是这样的：
GET /articles/aid/comments:某篇文章的评论列表GET /comments/cid:获取某文章的某评论详情POST /articles/aid/comments:在某篇文章中创建评论PUT /comments/cid:修改评论PUT /comments/cid:删除评论
这里有一点比较特殊，永远去使用可以指向资源的最短URL路径，也就是说既然/comments/cid:已经可以指向一条评论了，就不需要/articles/id/comments/cid:特意的指出所属的文章了。
GET /articles/id/like:查看文章是否被点赞PUT /articles/id/like:点赞文章DELETE /articles/id/like:取消点赞
接口版本
随着业务的调整，可能老接口不能再满足业务需求。这个时候我们尽可能加字段，或者新加接口。例如：1
api.github.com/v1/users
Token和Sign
API需要设计成无状态的，所以客户端在某些请求中需要带上token或者sign。
- Token 用于监听请求所属用户，一般都是服务端在登录后随机生成一段字符串（UUID）和登录用户进行绑定，再将其返回给客户端。Token的状态保持一般有两种方式实现：一种是在用户每次操作都会延长或者重置TOKEN生存时间（类似于缓存的机制），另一种是TOKEN的生存时长固定不变。
- Sign 用于证明该次请求合理，所以一般客户端会把请求参数拼接后加密作为Sign传给服务端，这样即使被抓包了，对方修改参数而无法生成对应Sign也会被识破。
业务参数
搜索1
/users/?query=iisheng
过滤1
/users/?gender=1
统计参数
这个一般可能的实现方案，是在行为接口后面添加参数像，业务参数一样，还有一种实现方案是单独写一个接口，只做统计用，我感觉这种方式更好一些。
分页
1 | /users/?offset=10&limit=10 |
1 | /articles/?cursor=2015-01-01 15:20:30&limit=10 |
1 | /users/?page=2&pre_page=20 |
返回数据
- Json比Xml可视化更好，也更省流量所以尽量使用Json。
- 创建和修改成功后需要返回该资源的全部信息。
- 返回数据不需要和客户端界面耦合。不要在API设计的时候就考虑少返回几个字段，少一次查询（比如用join）能带来多大性能提升。一定要以资源为单位，即使客户端一个页面需要展示多个资源，也不要在一个接口中全部返回。而是让客户端分别请求多个接口（也可以使用一个单独的服务（API网关），内部RPC调用基础服务，构造客户端需要的数据，返回给客户端，这样，客户端可以只调用少量接口）
