RESTful风格的api

RESTful概念

RESTful是一种理念，一种设计规范，并不是什么协议等。
REST，全称Representational State Transfer，直接翻译就是：表现层状态转化。但是这个缺少主语，实际上应该是“资源在网络中以某种表现形式进行状态转化”。

“资源”是RESTful中最核心的概念之一。在RESTful概念中，互联网中的每一样信息都可以定义为资源，比如文本、图片、音频、视频等。而这些资源又都可以对应一个特定的URI(统一资源定位符)，URI为每一个资源的地址或独一无二的识别符。

表现层，针对上面的“资源”，我们要进行相应的呈现，而且可以采用多种的呈现形式，而这些呈现形式就叫做“表现层”。eg:文本的呈现形式，JSON格式、XML格式、HTML格式等。

状态转化，资源通常放在服务器端，而客户端对服务器资源的增、删、改、查等操作，让资源状态发生改变。这个过程便是“ 状态转化”。

RESTful规范

在RESTful架构中，每个网址代表一种资源（resource），所有网址请求接口中不能有动词，只能有名词,这点和数据库设计风格很像。
RESTful一般使用规范（大部分情况下这样）：
（1）每一个URI代表一种资源；
（2）客户端和服务器之间，传递这种资源的某种表现层；
（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

HTTP方法	安全性	幂等性	接口说明
GET	安全	幂等	获取资源（Read）
POST	不安全	非幂等	创建资源（Create）
PUT	不安全	幂等	更新资源（Update）
DELETE	不安全	幂等	删除资源（Delete）

RESTful例子

以用户的增删查改为例：

get ： /user/list  //获取所有用户信息
post：/user  //创建用户信息
put：/user/123  //更新用户123的信息
get：/user/123  //获取资源标识（id）为123的用户信息
delete：/user/123  //删除资源标识（id）为123的用户信息

我在这里的没有使用资源的复数形式，如果使用资源的复数形式，查询所有用户还存在另一种表达，

get ： /users  //获取所有用户信息

单复数的资源形势表达在这里不做讨论，只要能让人正确理解就行，我个人一般只使用单数形式。

其次，资源的表达也是需要层级的
eg：
每个用户下拥有多本书：

get /user/123/book/list  //查询用户123的书籍列表
get /user/123/book/3  //查询用户123的id为3的书

部门下有多个用户

get /department/1/user/list //查询id为1的部门的用户列表
get /department/1/user/123 //查询id为1的部门下的用户123的信息