RESTful 是什么？
一种软件架构，设计风格，全称为 Representational State Transfer，但并不是标准，只是风格，根据该风格开发的 api 也简洁、易管理。
RESTful 有什么用？
一套接口应该满足以下几点：
- 安全可靠，高效，易扩展。
- 简单明了，可读性强，没有歧义。
- API 风格统一，调用规则，传入参数和返回数据有统一的标准。
RESTful 的设计理念基于 HTTP 协议，它是一种设计风格，没有规定一定如何实现，但是提供了很好的设计理念。
风格的统一，使得不需要过多的解释，就能让使用者明白该如何使用，同时也会有很多现成的工具来帮助我们实现 RESTful 风格的接口
设计原则
一、HTTPS
防止数据在传输过程中被篡改和窃听。
二、域名
将 api 请求接口与区分开，例如
https://api.huasio.com
// or
https://www.huasio.com/api
三、版本控制
随之时间的改变，项目api也肯定会有所更改，所以开发新版本的 api 得时候需要更好的管理 api 版本。
例如：将版本号直接加入 URL 中
https://api.larabbs.com/v1
https://api.larabbs.com/v2
使用 HTTP 请求头的 Accept 字段进行区分
https://api.larabbs.com/
Accept: application/prs.larabbs.v1+json
Accept: application/prs.larabbs.v2+json
四、URL 定位资源
在 RESUful 中，一切皆是资源，每一个 URL 就是一个资源。资源应该是名词，并且多数时候是复数。
五、资源过滤
提供合理的参数，请求合适数据。
六、状态码
HTTP 提供的状态码：
- 200 OK - 对成功的 GET、PUT、PATCH 或 DELETE 操作进行响应。也可以被用在不创建新资源的 POST 操作上
- 201 Created - 对创建新资源的 POST 操作进行响应。应该带着指向新资源地址的 Location 头
- 202 Accepted - 服务器接受了请求，但是还未处理，响应中应该包含相应的指示信息，告诉客户端该去哪里查询关于本次请求的信息
- 204 No Content - 对不会返回响应体的成功请求进行响应（比如 DELETE 请求）
- 304 Not Modified - HTTP缓存header生效的时候用
- 400 Bad Request - 请求异常，比如请求中的body无法解析
- 401 Unauthorized - 没有进行认证或者认证非法
- 403 Forbidden - 服务器已经理解请求，但是拒绝执行它
- 404 Not Found - 请求一个不存在的资源
- 405 Method Not Allowed - 所请求的 HTTP 方法不允许当前认证用户访问
- 410 Gone - 表示当前请求的资源不再可用。当调用老版本 API 的时候很有用
- 415 Unsupported Media Type - 如果请求中的内容类型是错误的
- 422 Unprocessable Entity - 用来表示校验错误
- 429 Too Many Requests - 由于请求频次达到上限而被拒绝访问
七、调用频率
为避免攻击，以及恶意请求，应该对 ip 限制请求次数。到了阈值之后对 ip 禁止请求等一些处理。
八、数据响应格式
一般常用的数据格式是 JSON，若需要 XML，需要在 Accept 头指定数据格式。
九、编写文档
编写接口，当然得配备对应得文档，一般来说需要包含以下几点：
- 包括每个接口的请求参数，每个参数的类型限制，是否必填，可选的值等。
- 响应结果的例子说明，包括响应结果中，每个参数的释义。
- 对于某一类接口，需要有尽量详细的文字说明，比如针对一些特定场景，接口应该如何调用。
十、使用 HTTP 动词描述请求操作
HTTP 提供的一些动词操作，RESTful 也利用了这些动词。
术语：幂等性：意思就是，一次或多次访问同一个资源的数据一致性。
| 动词 | 描述 | 是否幂等 |
|---|---|---|
| GET | 获取资源 | 是 |
| POST | 创建资源 | 否 |
| PUT | 更新资源，客户端提供完整的资源数据 | 是 |
| PATCH | 更新资源，客户端提供部分的资源数据 | 否 |
| DELETE | 删除资源 | 是 |
本文由 想起个优雅名字 创作，采用 知识共享署名4.0
国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名