一、什么是RESTFul
RESTful是基于http方法的API设计风格而不是一种技术。可以说使用这种设计风格我们看到url就知道要什么样的资源、看到http method就知道要针对资源干什么、看到http的 status code就知道结果是什么。使用RESTFul风格的api规范了程序员的代码开发，为前后端的交互减少了接口交流的口舌成本。
二、RESTFul风格的具体体现
2.1 REST 面向资源的（名词）
REST通过URI暴露资源的时候，会强调不要再 URI 中出现的动词，比如：
| 不符合REST的接口的URI | 符合REST接口的URI | 功能 |
|---|---|---|
| GET /api/getDog | GET /api/dogs/{id} | 获取一个小狗狗对象 |
| GET /api/getDogs | GET /api/dogs | 获取所有小狗狗对象 |
| GET /api/addDog | POST /api/dogs | 添加一个小狗狗对象 |
| GET /api/editDog/{id} | PUT /api/dogs/{id} | 修改一个小狗狗对象 |
| GET /api/deleteDog/{id} | DELETE /api/dogs/{id} | 删除一个小狗狗对象 |
从上面的表格中我们可以看出，RESTFul风格的接口通过 URI 来暴露资源的时候里面是没有动词的
2.2. 那么问题来了，那么怎样体现对资源的操作呢
2.2.1 用HTTP方法体现对资源的操作
| 方法 | 功能 |
|---|---|
| GET | 获取资源 |
| POST | 添加资源 |
| PUT | 修改资源 |
| DELETE | 删除资源 |
2.3 HTTP状态码
通过 HTTP 状态码来体现状态的结果，结果无非是两种情况，成功、客户端错误、服务器端错误
| 状态码 | 显示的消息 | 表示的意义 |
|---|---|---|
| 200 | OK | 所有事情按照预期正确执行完毕 - 成功 |
| 400 | Bad Request | API发生了一些错误 - 客户端错误 |
| 500 | Internal Server Error | API 发生了一些错误 - 服务器端错误 |
2.4 相关注意事项
- Get方法和查询参数不应该改变数据，改变数据的事情交给POST、PUT、DELETE
- 使用复数名词，而不要使用单数名词
- 复杂资源关系的表达
GET /cars/711/drivers/ 返回使用 car 711的所有司机
GET /cars/711/drivers/4 返回使用car 711的4号司机
2.6高级用法：：HATEOAS
HATEOAS 的全称为 Hypermedia as the Engine of Application State（超媒体作为应用状态的引擎），什么意思呢，就是返回结果中提供链接，连向其它API方法，使得用户不查文档也知道下一步应该做什么。
例子如下：
{
"link":{
"rel":"collection https://www.example.com/zoos",
"href":"https://api.example.com/zoos",
"title":"List of zoos",
"type":"application/vnd.yourformat+json"
}
}
这里表示，文档中有一个link属性，用户读取这个属性就知道下一步该调用什么API了。
2.8为集合提供过滤、排序、选择和分页等功能
Filtering过滤：
使用唯一的查询参数进行过滤：
GET /car?color=red 返回红色的cars
GET /car?seats<=2 返回小于两座位的cars集合
Sorting排序：
允许对多个字段进行排序
GET /cars?sort=-manufactor,+model
这个意思是返回根据生产者降序和模型升序排列的car集合，减号表示倒序，加号表示升序
Filed selection
移动端能够显示其中的一些字段，它们其实不需要一个资源的所有字段，给API消费者选择一个字段的能力，这样会降低网络流量，提高API的可用性。
GET /cars?fileds=manufactor,model,id,color
Paging分页
使用 limit 和 offfset ，实现分页，缺省limit=20 和offset =0:
/cars?offset=10&limit=5
2.9版本化你的API
使得API版本变得强制性，不要发布无版本的API。
/api/v1/blog 面向扩展开放，面向修改关闭，在这里v1就是指的版本
注：上述笔记来自于笔者平时看视频整理所得，如有侵权还请联系删除
