第34讲 | 基于JSON的RESTful接口协议：我不关心过程

1 RESTful 是一种架构风格 , Representational State Transfer , 表述性状态转移 , 来自<架构风格与基于网络的软件架构设计>
2 REST API简单直接 , 基本是互联网应用的标准接口
3 其实SOAP也能用REST风格 , 但设计初衷不一样
4 本地调用和远程调用的问题是 , 远程调用的时候 , 谁来维护状态 (如某个数据处理到什么程度)
5 例子: cd a , cd a 本地维护了路径的状态 , 因此实际路径是 /a/a
6 刚开始设计的时候没有考虑到状态维护的问题
7 翻页 , 下一页 , 下一页 , 是动作 , 状态由本地or服务端维护 , NFS的RPC就是类似的
8 REST是把状态转移给客户端自己负责了 , 以资源为核心 , 比如 list?page=100
9 由于客户端和服务端的比例失衡了 , 由服务端维护状态的压力增大
10 服务端只记录资源的状态 (这个不好理解)

image.png
image.png

11 从上面两句来看 , 实际就是把会话状态从服务端转移到了客户端
12 客户端自己维护自己的状态 , 访问到哪一页什么的
13 实际上只改进了get , 但也是巨大的改进

image.png

14 从已过程为核心 转变成 已资源为核心

image.png

15 案例 , 文件目录访问 , 减库存

image.png

16 这种API设计需要幂等 , 因为网络不稳定 , 可能发生重试产生重复请求
17 幂等 : 同一个调用 , 多次调用的结果需保持一致
18 例子: 支付一次 , 调用了3次 , 变成了支付3次 , cd a 调用了3次 变成cd /a/a/a , 减库存 , 扣了3次
19 REST API 无状态 , 面向资源 , 幂等 , 横向扩展 , 可缓存
20 REST API 传输问题 HTTP ,协议约定 JSON , 服务发现 - 有个注册中心 , 有新服务就过去注册 , 需要服务就去查
21 著名的REST API 的服务发现解决框架 , SpringCloud
22 SOAP的设计是面向动作的 , 因为架构问题 ,并发量上不去
23 RESTful不仅是一个API , 也是一种架构模式 , 上面说的面向资源 , 无状态 , 横向扩展 , 高并发
24 库存那个例子有很大问题 , 什么问题?
25 REST和SOAP其实就是基于文本的RPC ,

image.png

26 写一篇REST的文章 , 做好前期准备 ,画图定义伪代码 , 整体文章结构

从早期的计算机的以过程为核心发展(如SOAP协议)为以资源为核心的一种架构风格 , 访问资源的方式从只发送命令,由服务端维护当前用户的资源处理到什么程度,比如当前是第几页 ,只需要next()就可以到下一页, 转为客户端自己保持资源的处理进度 , 比如?page=100 , 下一页则是?page=101
get获取资源,post ,put,delete修改资源
将状态维护的压力分摊到客户端,缓解服务端的压力 ,同时使得横向扩展变得简单
此时会遇到一个幂等的问题,由于网络环境问题产生的重试,一个请求的一次调用需要保证和多次调用的结果一致 , 如调用支付3次,不会产生3笔支付,依然是1笔