api请求时长与请求数据类型的设计

前言

在咱们的业务请求中，有不少时候会针对有不一样时长的需求策略性设置。这里针对这个需求进行详细的展开。

针对这种状况，咱们的timout的通常是根据请求地址来的，因此核心处理技巧即是如何根据不一样的request地址去设置不一样的timeout.

咱们以前设置的请求时长是十秒，而且是经过create的部分，整个项目只有一个instance的。

let _axios = axios.create({
  baseURL: apiProxyUrl,
  headers: { 'Content-Type': 'application/json' },
  transformRequest: [transformRequest],
  timeout: 10000 
})复制代码

那么既然须要处理request的地址部分，我建议针对长时长的地址单独一个文件维护，考虑到了如下两点：

1 请求地址变多时，能够更好的定位以及维护
2 须要时，能够针对不一样的微服务进行进一步的管理和配置
3 与下面请求时长的策略部分进行解耦复制代码

主要结果是返回一个指望长时长地址的数组。

/**
 * @author robin
 * @description maintain all long time api request paths
 */
 
/**
 * 用户服务长时长地址数组
 */
const userApiPaths = [] 

/**
 * 报表服务长时长地址数组,若是你的微服务地址符合一个规律，能够这里进行方法定义并返回
 */
const getTablesApiPaths = ()=>{
    return []
}

export default [
    '/house/list/houseSpaceInHouseSpaceManager'
].concat(userApiPaths).concat(getTablesApiPaths())复制代码

简单处理

咱们知道axios自己的request支持拦截器的配置，那么咱们能够进行如下简单的设置。

import longTimeApiEnum from './longTimeApiEnum'
// 请求拦截器
_axios.interceptors.request.use((config) => { 
  // 请求时长10分钟
  const LONG_TIMEOUT = 600000 
  if (longTimeApiEnum.some(url => config.url.includes(url))) {
    config.timeout = LONG_TIMEOUT
  }
  return config
})复制代码

此方法适用于大部分请求地址没有规律性，适合用枚举维护相应地址的。

策略模式处理

固然若是你的长时长的api地址具备必定的正则可匹配性，也能够用正则来写，而且把判断的部分用策略模式独立为一个方法，甚至一个文件。

好比下面的例子：

// 根据微服务一级地址判断
function judgeIsLongTimeApi(url){
  const strategy = {
      'user':function(url){
          if(url.includes('/users/data')) return true;
          return false
      },
      'table':function(url){
          if(url.includes('/table')) return true;
          return false
      }
  }

    const firstPath = url.split('/')[1];
    return strategy[firstPath] && strategy[firstPath](firstPath);
    
}

// 使用
const LONG_TIMEOUT = 600000 
  if (judgeIsLongTimeApi(config.url)) {
    config.timeout = LONG_TIMEOUT
  }复制代码

复杂的类处理

感受上面的方式不够逼格，或者有时候不是这么简单的改一个timeout，还须要改不少配置，好比说baseUrl等等。那么你须要定义一个class。而后根据你的需求去自定义每一个子类。大概是这样的:这里用到了class继承。

import axios from 'axios';
class Api{
    constructor(){
        
    }
    nessaryFn(){
        throw Error('必需要实现的函数')
    }
    
    
}

class usualApi extends Api {
    constructor(){
        
    }
    nessaryFn(){
       //codes here
    }
}

class specialApi extends Api {
    constructor(){
        
    }
    nessaryFn(){
       //codes here
    }
}

// 再来一个策略模式 根据不一样的状况 ，返回使用不一样的api实现子类。复制代码

小结

以上就是所有的关于axios部分的自定义时长作的思考和实践，已经完整的解决了本身的需求。

其余问题

请求数据类型或者返回类型很是规时

好比当axios的请求返回类型为非json类型，须要针对url进行特殊化配置的时候，相应的思路也是如此。

方式一：能够经过维护关键路径来特殊处理

if (exportXlsEnum.some(url  =>  config.url.includes(url))) {
config.responseType  =  'blob'
}复制代码

方式二：策略的方式，当符合某种策略，特定的设置某些配置参数以及改变返回结果的校验，那么api方法定义时，直接增长传入策略名称便可

方式三：若是具备大量的接口具备这样的特征，也能够直接实例化支持该配置的axios实例，调用时直接使用该实例，与常规的axios请求实例区别开。

关于我

• 我是一名前端Coder，热爱分享生活与技术中的经验与心得。
• 我是一名旅游爱好者，爱好拍摄旅途中的风景与人物。
• 我是一名写做狂人，基本天天都有新文章产出，笔耕不辍。

我的站点

• GitHub：http://github.com/robinson90
• codepen：https://codepen.io/robinson90
• personal blog: http://damobing.com
• yuque docs: https://www.yuque.com/robinson
• juejin blog: https://juejin.im/user/5a30ce0c51882561a20a768b

我的微信号与公众号

微信：csnikey,或者扫码加我

达摩空间订阅号：damo_kongjian，或者扫描下面的二维码