RESTful 入门
一、什么是Restful
- REST 是 Representational State Transfer 的缩写,如果一个架构符合 REST 原则,就称它为 RESTful 架构
- RESTful 架构可以充分的利用 HTTP 协议的各种功能,是 HTTP 协议的最佳实践
- RESTful API 是一种软件架构风格、设计风格,可以让软件更加清晰,更简洁,更有层次,可维护性更好二、RESTful API 请求设计要按照:请求 = 动词 宾语 动词:使用五种 HTTP 方法,对应 CRUD 操作。 宾语:URL 应该全部使用名词复数,可以有例外,比如搜索可以使用更加直观的 search 。 过滤信息(Filtering) 如果记录数量很多,API应该提供参数,过滤返回结果。 ?limit=10 指定返回记录的数量 ?offset=10 指定返回记录的开始位置。GET /departments 列出所有部门
POST /departments 新建一本部门 GET /departments/:id 获取某个指定的部门信息 PUT /departments/:id 更新某个指定的部门信息 PACH /departments/:id 更新某个指定部门的部分信息 DELETE /departments/:id 删除某一本部门
上述四个HTTP请求方法的安全性和幂等性如下:
HTTP Method | 安全性 | 幂等性 | 解释 |
---|---|---|---|
GET | 安全 | 幂等 | 读操作安全,查询一次多次结果一致 |
POST | 非安全 | 非幂等 | 写操作非安全,每多插入一次都会出现新结果 |
PUT | 非安全 | 幂等 | 写操作非安全,一次和多次更新结果一致 |
DELETE | 非安全 | 幂等 | 写操作非安全,一次和多次删除结果一致 |
三、传统模式 URI 和 RESTful 风格对比
- 查询
操作 | 传统 | RESTful |
---|---|---|
查询所有 | http://localhost:8080/employee/list | http://localhost:8080/employees |
查询单个 | http://localhost:8080/employee/list?id=1 | http://localhost:8080/employees/{id} |
- 新建
操作 | 传统 | RESTful |
---|---|---|
增加 | http://localhost:8080/employee/add | http://localhost:8080/employees |
- 修改
操作 | 传统 | RESTful |
---|---|---|
更新 | http://localhost:8080/employee/update | http://localhost:8080/employees |
- 删除
操作 | 传统 | RESTful |
---|---|---|
删除 | http://localhost:8080/employee/delete | http://localhost:8080/employees/{id} |
四、状态码和返回数据
服务端处理完成后客户端也可能不知道具体成功了还是失败了,服务器响应时,包含状态码和返回数据两个部分。
1. 状态码
1xx 状态码
API 不需要1xx状态码,下面介绍其他四类状态码的精确含义。
2xx 状态码
200状态码表示操作成功,但是不同的方法可以返回更精确的状态码。
GET: 200 OK POST: 201 Created PUT: 200 OK PATCH: 200 OK DELETE: 204 No Content
上面代码中,POST返回201状态码,表示生成了新的资源;DELETE返回204状态码,表示资源已经不存在。
3xx 状态码
API 用不到301状态码(永久重定向)和302状态码(暂时重定向,307也是这个含义),因为它们可以由应用级别返回,浏览器会直接跳转,API 级别可以不考虑这两种情况。
API 主要是用303 See Other,表示参考另一个 URL。它与302和307的含义一样,也是"暂时重定向",区别在于302和307用于GET请求,而303用于POST、PUT和DELETE请求。收到303以后,浏览器不会自动跳转,而会让用户自己决定下一步怎么办。下面是一个例子。
HTTP/1.1 303 See Other Location: /api/orders/12345
4xx 状态码
4xx 状态码表示客户端错误,主要有下面几种:
400 Bad Request:服务器不理解客户端的请求,未做任何处理。 401 Unauthorized:用户未提供身份验证凭据,或者没有通过身份验证。 403 Forbidden:用户通过了身份验证,但是不具有访问资源所需的权限。 404 Not Found:所请求的资源不存在,或不可用。 405 Method Not Allowed:用户已经通过身份验证,但是所用的 HTTP 方法不在他的权限之内。 410 Gone:所请求的资源已从这个地址转移,不再可用。 415 Unsupported Media Type:客户端要求的返回格式不支持。比如,API 只能返回 JSON 格式,但是客户端要求返回 XML 格式。 422 Unprocessable Entity :客户端上传的附件无法处理,导致请求失败。 429 Too Many Requests:客户端的请求次数超过限额。
5xx 状态码
5xx状态码表示服务端错误。一般来说,API 不会向用户透露服务器的详细信息,所以只要两个状态码就够了。
500 Internal Server Error:客户端请求有效,服务器处理时发生了意外。 503 Service Unavailable:服务器无法处理请求,一般用于网站维护状态。
2. 返回结果
2.1. 不要返回纯本文
API 返回的数据格式,不应该是纯文本,而应该是一个 JSON 对象,因为这样才能返回标准的结构化数据。所以,服务器回应的 HTTP 头的Content-Type属性要设为application/json。
客户端请求时,也要明确告诉服务器,可以接受 JSON 格式,即请求的 HTTP 头的ACCEPT属性也要设成application/json。
2.2. 不要包装数据
response 的 body直接就是数据,不要做多余的包装。错误实例:
代码语言:json复制{"success":true, "data":{"id":1, "name":"周伯通"} }
针对不同操作,服务器向用户返回的结果应该符合以下规范。
GET /collection:返回资源对象的列表(数组) GET /collection/resource:返回单个资源对象 POST /collection:返回新生成的资源对象 PUT /collection/resource:返回完整的资源对象 PATCH /collection/resource:返回完整的资源对象 DELETE /collection/resource:返回一个空文档
2.3. 发生错误时,不要返回 200 状态码
有一种不恰当的做法是,即使发生错误,也返回200状态码,把错误信息放在数据体里面,就像下面这样。
代码语言:json复制{"status": "failure", "data": { "error": "Expected at least two items in list."} }
正确的做法是,状态码反映发生的错误,具体的错误信息放在数据体里面返回。下面是一个例子。
代码语言:json复制HTTP/1.1 400 Bad Request Content-Type: application/json
{
"error": "Invalid payoad.",
"detail": {
"surname": "This field is required."
}
}