REST介绍，实质，六大约束，优缺点（数据冗余问题，身份验证困难（解决方式 -- JWT+集中式认证服务,使用代理））
目录
REST
介绍
实质
六大约束
客户端 - 服务器（Client-Server）
无状态（Stateless）
可缓存（Cacheable）
统一接口（Uniform Interface）
分层系统（Layered System）
按需代码（Code on Demand）
优点
可复用性
缺点
数据冗余
身份验证困难
引入
性能问题
JWT+集中式认证服务
JWT
介绍
是否保证无状态
使用代理
介绍
信任代理
网关认证逻辑
是否保证无状态
REST
介绍
REST是缩写，全称是（Resource） Representational State Transfer
- 意思是：资源在网络中以某种表现形式进行状态转移
- Resource：资源，即数据 -- REST的核心理念，一切皆资源 （每个资源通过一个唯一的 URL 标识）
- Representational：某种表现形式（JSON，XML，JPEG等），都是可协商的（不同端都可解析）
- State Transfer：状态变化 -- 通过HTTP的动词（get查询、post新增、put修改、delete删除）等实现，其中http是最常用的实现方式
它不是具体的协议或标准，而是一组设计原则，用来构建 可扩展、可维护的分布式系统 —— 尤其是 Web API
实质
REST = 用 URL 定位资源，用 HTTP 方法定义操作，用状态码表达结果，用 JSON/其他 传输数据
六大约束
客户端 - 服务器（Client-Server）
职责分离，客户端负责界面与交互，服务器负责数据与逻辑
无状态（Stateless）
每次请求都是独立的 -- 服务端不记得上一个请求+每个请求都能独立完成+服务器根据请求中的全部信息作出响应
- 所有状态信息应由客户端在每次请求中携带
- 服务器不在内存中保留客户端会话状态
可缓存（Cacheable）
REST系统需要可以缓存请求，以提高效率与性能
- 在服务器响应中指明是否可缓存
统一接口（Uniform Interface）
客户端与服务器之间应该依赖统一、标准化的交互接口，从而降低耦合
- 接口条件在上面的[实质]中有介绍
分层系统（Layered System）
架构可以由分层组成（负载均衡、缓存层、网关、代理、后端服务），客户端不必知道它与最终服务器之间中间有哪些层
- 但也要保证可观测性（添加日志等）
按需代码（Code on Demand）
服务器可向客户端传输可执行代码（如 JavaScript），以扩展客户端功能
- 非必须
而满足了以上条件设计的 Web 服务，就是RESTful的
- 其中，严格遵循 REST 设计原则的系统称为 RESTful 系统
- 而遵循部分原则但核心思想一致的，也可称为 REST-like 或 REST-style 系统
优点
其中，重点说说可复用性
可复用性
后端处理数据后需要发给客户端，如果有多种客户端（web，ios，android）：
传统接口设计中，需要为不同客户端定义不同请求/返回格式，并且配套写多种处理逻辑
使用 REST 之后，就几乎可以做到“一套接口通吃所有客户端”
其中：
- REST 规定所有通信都使用 HTTP 协议（跨平台通用协议，不依赖具体框架）
- 统一使用url定位资源，不管谁来访问，都是一样的
- 返回的json数据可以被各种端解析
- 无状态使得不同客户端的请求不会相互影响，服务器只关心“请求内容”，不关心是谁发来的
缺点
数据冗余
因为REST是面向资源的，请求/响应返回的数据粒度也自然是资源级，而不是字段级
- 所以如果要获取某个用户的某个信息，发送的url也只会是定位的整个用户资源，而不是其中一个信息
- 那么返回的也是完整的用户对象
- 这就会造成数据冗余
身份验证困难
引入
在现有的基于http的web服务中，一般使用会话来管理用户状态，那么服务端内部就需要维护用户的登录状态
- 但REST的无状态约束却不希望这样
- 因为REST的优势就在于横向扩展性，不同端发送的请求可能被REST服务集群中的任意服务器处理
- 那么由服务端维护状态，显然就不现实
性能问题
于是，REST架构最纯粹的解决方式就是 -- 由客户端每次带上需要的用户信息，服务器根据这些信息验证权限后，才能处理请求
- 但是每次请求都要身份验证 + 现代系统使用复杂的哈希算法保证安全，使得登录验证变成一个重操作，影响高并发性能
所以，通过把认证开销“做一次或者集中做”来提高整体吞吐与响应速度
JWT+集中式认证服务
系统中设置一个独立的认证服务，用户首次登录时验证用户名和密码，通过后该服务生成一个凭证，后续请求皆携带该凭证，后端通过验签确认身份
JWT
JWT（JSON Web Token）,自包含的数字凭证
介绍
Auth Server 使用私钥签发短周期 access token（含 user_id、roles、exp），客户端保存并每次请求带上该token，后端使用公钥本地验签并读取用户信息
- Auth Server 签发JWT本身不需要状态 -- 因为不需要保存token，客户端下次请求时，Auth Server只要验证签名正确且未过期，就能确定用户身份
- 缺点：一旦签发出去，就在有效期内始终有效，如果被盗，攻击者可以在有效期内任意使用
是否保证无状态
服务端处理请求时，只需验证 token 签名，不需要访问其他，所以是无状态的
- 但现实系统通常会为了安全或功能需求引入一点“状态性”
使用长期refresh_token（用来刷新新的access_token） + 短期JWT（访问资源用）的形式，来增强系统安全性
- 频繁使用的access_token即使被盗，也会很快过期，暴露风险就降低了
- 但是认证服务需要存储refresh_token，存在轻量状态
使用代理
介绍
把认证全部集中在网关入口，在转发时注入内部header（包含用户信息），后端服务信任[经过网关的请求]，直接读取header即可进行业务处理
- 这样后端可以不做验签或查缓存，省去重复开销
- 由网关保存用户的登录状态
信任代理
如何做到信任代理呢？
- “信任”是需要手动配置的 -- 后端不能自动信任任何header，必须配置网关来源验证机制
网关认证逻辑
其中，网关认证逻辑可以有两种
是否保证无状态
- 业务后端确实无状态，但整体来看还是有轻微状态
