前端开发--总结

封装Fetch，统一API接口请求

2024-06-23  本文已影响0人  cychen7

说真的，从来没有想过，要写些关于开发经验的文章，很多的时候遇到了问题解决问题就结束了。至于后面还会不会再次遇到，再说。今天之所以要写这一篇文章，也是朋友说起，做程序员这么些年，经验怎么滴也是有很多的，是可以给分享更多的兴趣爱好者共同学习。但从大脑里搜寻了很久，发现我真不知道要写什么，感觉有很多，感觉又什么都没有。翻看了一下项目，决定从这个Api请求接口入手，毕竟这个我改了10来版了，改的我真的不晓得要说啥好了。

先说说缘由，很早之前并没有Api接口请求统一入口，只是做了简单的请求拼接。每个请求都需要带上请求凭证，凭证过期了，又需要重新获取凭证再重新调用，如果是表单提交时，凭证过期了，提交的数据没做存储，最后又得重新录入表单重来一次；另外就是重复提交的问题，操作频率太迅速，表单重复提交了；再就是协作合作时，不同的人对错误的处理……

实现内容

  1. 统一的接口地址和前缀
  2. 请求拦截器
    2.1 设置请求头
    2.2 防止重复请求
  3. 响应拦截器
    3.1 错误处理
  4. 请求锁

搭建基本结构

新建fetch.js文件

export default function _fetch(options) {
  return new Promise((resolve, reject) => {
    const instance = axios.create({
      baseURL: '/api/v1',
      timeout: 20000,
      headers: { 'Content-Type': 'application/json' }
    })

    // http request 请求拦截器
    instance.interceptors.request.use(async (config) => {
    }, err => {
      return Promise.reject(err)
    })

    // http response 响应拦截器
    instance.interceptors.response.use((response) => {
      resolve(res)
    }, error => {
       // 错误处理
      errorHandle(error, reject)
    })

    instance(options)
  })
}

接下来，就来填充实现吧

统一的接口地址和前缀

baseURL 属性是请求地址前缀，将自动加在 url 前面。正常情况下，在开发环境下和生产模式下有着不同的 baseURL，所以，我们需要根据不同的环境切换不同的 baseURL。
不过这里只配置了地址前缀，用了服务器代理；如果不用代理或不是发布在同服务器的时候，可以根据环境直接配置接口地址

 baseURL: process.env.NODE_ENV === 'production' ? 'http://192.168.1.1:3000/api/v1' : 'http://192.168.1.1:3000/prop-api/v1'

请求拦截器

拦截 request 请求,处理一些发送请求之前做的处理,譬如给 header 加 token 等

// 判断token
let token = store.getters.token
if (!token || !token.access_token ) {
  directLogin()
  return Promise.reject(new Error('未登录授权'))
}
if (isValidToken(token, 'access_token')) { // 未过期
  config = setHeader(config, token)
  return config
}

// 给header添加统一的配置，如token、登录用户等
const setHeader = (config, token) => {
  config.headers = config.headers || {}
  config.headers.Authorization = token.token_type + ' ' + token.access_token

  const user = store.getters.user
  if (user && user.username) {
    Object.assign(config.headers, { 'creatorId': user.username })
  }

  return config
}

防抖是在一定时间间隔内只执行一次函数，而节流是在一定时间间隔内最多执行一次函数。这两种技术可以有效防止用户频繁触发事件导致的重复请求。

这里的拦截原理其实也是特别简单：就是把请求存起来，在下一个请求进入时判断，与上一个执行中的请求是否一样，一样就执行“axios.cancel"操作取消请求；

// post/put拦截，避免重复提交
if (config.method.toLowerCase() === 'post' || config.method.toLowerCase() === 'put') {
  removePending(config) // 在一个请求发送前执行一下取消操作
  config.cancelToken = new CancelToken((c) => {
    pending.push({ url: config.url + '&' + config.method, f: c }) // 请求地址&请求方式拼接的字符串
  })
}

let pending = [] // 声明一个数组用于存储每个请求路径和取消函数
let CancelToken = axios.CancelToken
let removePending = (config) => {
  let flagUrl = config.url + '&' + config.method
  for (let item in pending) {
    if (pending[item].url === flagUrl) { // 当当前请求在数组中存在时执行函数体
      pending[item].f() // 执行取消操作
      pending.splice(item, 1) // 把这条记录从数组中移除
    }
  }
}

响应拦截器

1、重复请求，在请求完成后，请求也需要从暂存的请求组中释放；2、 返回的数据很多都是我们不需要的,我们需要的只有 data 中的数据；3、请求异常处理

// http response 响应拦截器
instance.interceptors.response.use((response) => {
  if (response.config.method.toLowerCase() === 'post' || response.config.method.toLowerCase() === 'put') {
    removePending(response.config)
  }

  const res = response.data
  resolve(res)
}, error => errorHandle(error, reject))

错误处理

// 错误处理
const errorHandle = (error, reject) => {
  pending = []
  // util.showMsg('出错啦！请稍后再试试哦～')
  if (axios.isCancel(error)) {
    return reject(new Error('该请求在axios拦截器中被中断'))
  }

  if (error.response) {
    let data = error.response.data
    let status = error.response.status
    switch (status) {
      case 400: // 业务请求异常
        if (data.error === 'invalid_grant') {
          ShowTip('用户名或密码错误')
        } else if (data.status === 401) {
          directLogin(data.message)
        } else {
          ShowTip(data.message)
        }
        return reject(data)
      case 401: {// 未授权 清除token信息并跳转到登录页面data.error_description
        let message = data.error === 'unauthorized' ? '您的账号已被停用，请联系管理员' : null
        directLogin(message)
        break
      }
      default: // 其他错误
        if (httpCode[status]) {
          console.log(`服务器错误！错误代码：${status}；` + httpCode[status])
        }
        break
    }
  }
  return reject(error)
}

请求锁

请求锁，原理跟”防止请求重复提交“是一样的；不过这里的请求锁是针对”token“的。相信在做开发的时候，都遇到这么个痛点，在输入了一堆的表单数据后提交，token过期，直接跳回了登录页；小数据量的表单也就忍了，当表单内容特别的多时，出现这样的情况，时真的想.....。因此这里需要：无感刷新token，先上代码

// 在请求拦截中判断
if (!getTokenLock) {
  getTokenLock = true
  store.dispatch('refresh').then(res => { // 刷新Token
    getTokenLock = false
    onAccessTokenFetched(res)
    return res
  }).catch(res => {
    directLogin()
    return Promise.reject(res)
  })
}
return addSubscriber(config) // 存请求

全局定义getTokenLock

let getTokenLock = false // Token锁标记

解释：登录凭证token也是异步调用接口拿到的，所以在请求拦截中判断，是否在请求token，如果是，就先将当前的请求存起来；token拿到后，在把存起来的请求，继续执行

function addSubscriber(config) {
  return new Promise((resolve) => {
    subscribers.push((token) => {
      // 因为config中的token是旧的，所以刷新token后要将新token传进来
      config = setHeader(config, token)
      resolve(config)
    })
  })
}

let getTokenLock = false // Token锁标记
let subscribers = [] // 获取token后，待执行的请求队列
function onAccessTokenFetched(token) {
  console.log('刷新token成功，执行队列')
  subscribers.forEach(cb => cb(token))
  subscribers = [] // 执行完成后，清空队列
}

总结

image.png
上一篇下一篇

猜你喜欢

热点阅读