「这是我参与2022首次更文挑战的第6天，活动详情查看：2022首次更文挑战」。
一.RESTful API简介
-
rest是一个风格，一个万维网软件架构 风格
-
rest全称：Representational State Transfer
- Representational：数据的表现形式（JSON，XML...），rest并不限制数据的表现形式，但一般用json。
- State: 当前状态或者当前的数据
- Transfer：数据传输
-
rest的六个规则：
-
客户-服务端(Client-Server)CS架构
- 关注点分离
- 服务端专注数据存储，提升了简单性
- 前端专注用户界面，提升了可移植性
-
无状态(Stateless)
- 所有用户会话信息都保存在客户端
- 每次请求必须包括所有信息，不能依赖上下文信息
- 服务端不会保存会话信息，提升了简单性(服务端因此减少了很多代码)，可靠性(一个软件的稳定程度，以及出故障的恢复能力。因为如果服务端需要管理会话信息，一旦出故障，那么信息就会完全丢失，想要恢复起来几乎不可能，所以可靠性非常差)，可见性(软件工程中那些模块的透明程度，因为每次请求都会发送所有的信息，所以接口之间会更加透明)
-
缓存(Cache)
- 所有服务端响应要分为可缓存和不可缓存的（比如前端的css，js资源就可以缓存，接口随时变动就不能缓存）
- 减少前后端交互，提升了性能
-
统一接口(Uniform Interface)
- 接口设计尽可能的统一通用，提升简单性，可见性
- 接口与实现解耦，使前后端可以独立开发迭代
-
分层系统（Layered System）
-
每一层只知道相邻的一层，后面隐藏的就不知道了
-
客户端不知道是和代理通信还是真实服务器通信，客户端只知道接口
-
其他层：安全层，负载均衡层，缓存层等
-
-
按需代码（Code-on-Demand）
- 客户端可以运行服务端传来的代码(比如JS，ssr)
- 通过减少一些功能，简化客户端
-
二.REST中的统一接口
-
资源的标识
-
资源是任何可以命名的事物，比如用户，评论等
-
每个资源都可以被URL唯一的标识
- api.github.com/users 所有的用户资源都在这一个接口下，需要访问用户只能通过这个接口
- api.github.com/users/chaxu… 如果需要访问特定的用户，需要加上用户id
-
-
通过表述来操作资源
-
表述就是Representation，比如JSON，XML等
-
客户端不能直接的操作服务端资源，比如SQL
-
客户端只能通过表述，比如JSON来操作资源
-
参考github API的例子
-
-
更新操作采用patch，每个字段表示一个意思
-
-
自描述信息
-
每个消息(请求或响应)必须提供足够的信息让接受者理解
-
媒体类型(application/json,application/xml)
-
HTTP方法：GET查，POST增，DELETE删
-
是否缓存：Cache-Control
-
参考github的自描述信息：docs.github.com/en/rest/ove…
-
-
请求类型的自描述信息
-
-
-
超媒体作为应用状态引擎
-
超媒体：带文字的链接
-
应用状态：一个网页
-
引擎：驱动
-
合起来：点击链接跳转到另一个网页
-
参考github例子：
-
-
三.RESTful API具体的风格
- 基本的URL，如api.github.com/users
- 标准的HTTP方法：如GET，POST，PUT，PATCH，DELETE
-
传输的数据媒体类型，如JSON，XML
-
举例：
- GET /users获取users列表
- GET /users/12 获取某个具体的user
- POST /users 新建一个user
- PUT /users/12 更新用户12的信息
- DELETE /users/12 删除用户12
- PTACH 部分更新
- POST transfer转移一个仓库
-
参考github API：docs.github.com/en/rest/ref…
-
请求规范：
- URL使用名词，尽量用复数，比如/users
- URL使用嵌套来表示关联关系，比如/users/12/repos/5
- 使用正确的HTTP方法，如GET/POST/PUT/PATCH
- 不符合CRUD的情况：
- POST+动词
- ?action
- 子资源
-
响应的设计规范
- 状态码，选择正确的状态码
- 字段过滤，返回的结果只能返回指定的字段，不是全部
- 分页，列表比较长需要进行分页
- 错误处理，尽量把错误信息进行返回
- 例子：docs.github.com/en/rest/ref…
