前后端分离

分离之前开发模式（串行）
提出需求 - 前端开发页面 - 翻译成模板 - 前后端对接 - 集成遇到问题 - 前端返工 - 后端返工 - 二次集成 - 集成成功 - 交付上线

分离后（并行）
image.png

  • 提高开发效率
  • 分工明确（前后端各司其职）
  • 增强代码维护性

RESTful API

一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

一、协议

API与用户的通信协议，总是使用HTTPs协议。

二、域名

应该尽量将API部署在专用域名之下。

  1. https://api.example.com

当然。如果确定API很简单，不会有进一步扩展，可以考虑放在主域名下。

  1. https://example.com/api/

三、版本

应该将API的版本号放入URL。

  1. https://api.example.com/v1/

另一种做法是，将版本号放在HTTP头信息中，但不如放入URL方便和直观。

四、路径（endpoints）

路径又称”终点”（endpoint），表示API的具体网址。

在RESTful架构中，每个网址代表一种资源（resource），所以网址中不能有动词，只能有名词，而且所用的名词往往与数据库的表格名对应。一般来说，数据库中的表都是同种记录的”集合”（collection），所以API中的名词也应该使用复数。

例如 有个 API 提供球队（teams）信息，还包括球员的信息，它的路径应该设计成如下：

  1. https://api.example.com/v1/teams
  2. https://api.example.com/v1/players

五、HTTP 动词

对于资源的具体操作类型，由HTTP动词表示。
常用的HTTP动词有下面五个（括号里是对应的SQL命令）。

  • GET（SELECT）：从服务器获取资源（一个或多个）
  • POST（CREATE）：在服务器新建一个资源
  • PUT（UPDATE）：在服务器更新资源
  • PATCH（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）
  • DELETE（DETELE）：从服务器删除资源（客户端提供改变的属性）
  • HEAD：获取资源的元数据
  • OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的
  1. GET /teams: 列出所有球队
  2. POST /teams: 新建一个球队
  3. GET /teams/ID: 获取某个球队的信息
  4. PUT /teams/ID: 更新某个球队的信息（提供球队的全部信息）
  5. PATCH /teams/ID: 更新某个球队的信息（提供球队的部分信息）
  6. DELETE /teams/ID: 删除某个球队
  8. // 一对多
  9. GET    /teams/ID/players: 列出某个指定球队的所有球员
  10. DELETE /teams/ID/players/ID: 删除某个球队中某个球员

六、过滤信息

如果记录数量很多，服务器不可能都将它们返回给用户。API应该提供参数，过滤返回结果。

  1. ?limit=10：指定返回记录的数量
  2. ?offset=10：指定返回记录的开始位置。
  3. ?page=2&per_page=100：指定第几页，以及每页的记录数。
  4. ?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序。
  5. ?animal_type_id=1：指定筛选条件

参数的设计允许存在冗余，即允许API路径和URL参数偶尔有重复。
比如，GET /teams/ID/players 与 GET /players?team_id=ID 的含义是相同的。

七、HTTP 状态码

状态码分为以下几类

1XX 信息性状态码 接收的请求正在处理
2XX 成功状态码 请求正常处理完毕
3XX 重定向状态码 需要进一步的操作来完成请求
4XX 客户端错误状态码 请求包含错误语法或者无法完成请求
5XX 服务端错误状态码 服务器在处理请求的过程中发生了错误

常见的状态码

  • 200 请求成功
  • 301 永久重定向。表示请求的资源已被分配了新的URI。
  • 302 临时重定向
  • 304 未修改。所请求的资源未修改。命中缓存返回304，服务器不会返回任何资源。
  • 400 客户端请求的语法错误，服务器无法理解
  • 401 请求要求用户的身份认证（表示用户没有权限）
  • 403 服务器理解客户端的请求，但是拒绝执行此请求（表示用户得到授权，但是访问是被禁止的）
  • 404 资源未找到
  • 500 服务器内部错误，无法完成请求
  • 503 服务器超载或系统维护
  • 504 网关超时

八、错误处理（Error handling）

如果状态码是4xx，就应该向用户返回出错信息。一般来说，返回的信息中将error作为键名，出错信息作为键值即可。

  1. {
  2.     error: 'Invalid API key'
  3. }

九、返回结果

针对不同操作，服务器向用户返回的结果应该符合以下规范。

GET /teams：返回资源对象的列表（数组） GET /teams/1：返回单个资源对象 POST /teams：返回新生成的资源对象 PUT /teams/resource：返回完整的资源对象 PATCH /teams/resource：返回完整的资源对象 DELETE /teams/resource：返回一个空文档

十、其他

在实际开发过程中，对于查询参数过多的接口，会导致 uri 的长度过长、请求失败，在这种情况下的接口就不能完全按照 Restful API 的请求规范来。

swagger 在线接口文档

url
method
Content-Type
params/body
response
…

axios 基本用法

axios: https://github.com/axios/axios

vuex

vuex: https://vuex.vuejs.org/zh/

image.png
更改 Vuex 的 store 中的状态的唯一方法是提交 mutation。
Action 可以处理异步，mutation 不行。
Action 提交的是 mutation，而不是直接变更状态。

async / await 让异步编程更简单

它们是基于 promises 的语法糖，使异步代码更易于编写和阅读。通过使用它们，异步代码看起来更像是老式同步代码。传送： https://developer.mozilla.org/zh-CN/docs/Learn/JavaScript/Asynchronous/Async_await

实现异步编程有哪些方式？
1、
2、
3、
4、async / await

loading

在body 添加 dom #back
使用 teleport 将组件挂载到指定 #back 节点

JWT

基于 cookie / session
image.png

1、用户向服务器发送用户名和密码。

2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。

3、服务器向用户返回一个 session_id，写入用户的 Cookie。

4、用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。

5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

基于 cookie / session 有状态的。验证记录或者会话必须同时保存在客户端/服务端。服务端必须跟踪记录，session必须存到内存或者数据库中，前端在cookie要保存对应的sessionId作为session的唯一标识符，可以看做session的身份证

拓展性差。 多台机器就要求 session 共享。每台服务器都能读取数据（数据持久化）

基于 token
image.png

JWT（JSON Web Token）的原理是，服务器认证以后，生成一个 JSON 对象，发回给用户，就像下面这样.

  1. {
  2.     name: 'zhangsan',
  3.   role: 'admin',
  4.   expires: '2022-01-01 00:00:00'
  5. }

以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。

服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。

JWT 三个部分由 . 连接起来。 https://jwt.io/#debugger-io

  • Header（头部）
  • Payload（负载）
  • Signature（签名）

Header
Header 部分是一个 JSON 对象，描述 JWT 的元数据，通常是下面的样子。

  1. {
  2.     "alg": "HS256",
  3.   "typ": "JWT"
  4. }
  • alg 属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）；
  • typ 属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。

最后，将上面的 JSON 对象使用 Base64URL 算法转成字符串

Payload
Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。

iss (issuer)：签发人 exp (expiration time)：过期时间 sub (subject)：主题 aud (audience)：受众 nbf (Not Before)：生效时间 iat (Issued At)：签发时间 jti (JWT ID)：编号

除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。

  1. {
  2.   "sub": "1234567890",
  3.   "name": "John Doe",
  4.   "admin": true
  5. }

注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。

这个 JSON 对象也要使用 Base64URL 算法转成字符串。

Signature
Signature 部分是对前两部分的签名，防止数据篡改。

首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。

  1. HMACSHA256(
  2.   base64UrlEncode(header) + "." +
  3.   base64UrlEncode(payload),
  4.   secret)

算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用”点”（.）分隔，就可以返回给用户。

JWT 服用方式
客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

  1. Authorization: Bearer <token>

其他

  • JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。

  • JWT 不加密的情况下，不能将秘密数据写入 JWT。

  • JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。

  • JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。

  • JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。

  • 为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

message

app.config.globalProperties.$message = message
const { proxy } = getCurrentInstance() as any