前端API自动化构建工具：讲述 FlyHttp 设计思想
上篇文章：FlyHttp 的诞生：从认识各种网络请求开始，本篇文章正式开始 FlyHttp 构建工具的设计，接下来让我们开始吧！
讲述 FlyHttp 设计思想
以 Vue.js 框架为例子，我们简单看一下，在进行项目开发中，使用 axios 在前端进行网络请求，我们需要进行哪些步骤？
1. 传统的开发流程
1.1封装 axios
在我们进行前端项目开发时，封装 axios 是必须的。因为每个项目业务可能都不一样，但是封装思想都是一样的，封装适合自己的 axios，不但可以统一管控自己的请求入口，还能大大节约请求工作量，这其中的好处不言而喻。
直接拿来我自己封装的 axios 核心代码，包括但不限于以下的简单形式：主要是构建实例，请求拦截等。
import axios, { AxiosInstance } from 'axios';
// 配置新建一个 axios 实例
const request: AxiosInstance = axios.create({
baseURL: import.meta.env.VITE_API_URL,
timeout: 50000,
headers: { 'Content-Type': 'application/json' },
});
// 添加请求拦截器
request.interceptors.request.use(
(config) => {
// 在发送请求之前做些什么，比如认证token
if ('token') {
config.headers!['Authorization'] = 'token';
}
return config;
},
(error) => {
// 对请求错误做些什么
return Promise.reject(error);
}
);
// 添加响应拦截器
request.interceptors.response.use(
(response) => {
// 对响应数据做点什么
const res = response.data;
if (res.status && res.status !== 200) {
return Promise.reject(request.interceptors.response);
} else {
return res;
}
},
(error) => {
// 对响应错误做点什么
if (error.message.indexOf('timeout') != -1) {
console.error('网络超时');
} else if (error.message == 'Network Error') {
console.error('网络连接错误');
} else {
if (error.response.data) console.error(error.response.statusText);
else console.error('接口路径找不到');
}
return Promise.reject(error);
}
);
1.2 开发请求 API
对以上简单封装后，我们就可以使用封装好的 axios 实例来进行编写请求方法了
import request from '@/utils/request'
// 定义接口地址
const api = {
useLogin: '/api/user/login', // 用户登录
useLogout: '/api/user/logout' // 用户登出
// ...等等还有很多接口地址
}
// 用户登录方法
export function useLogin(data) {
return request({
url: api.useLogin,
method: 'POST',
data
})
}
// 用户登出方法
export function useLogout(data) {
return request({
url: api.useLogout,
method: 'POST',
data
})
}
// ...等等还有很多方法
页面中使用方式如下：
import api from '@/api'
// 用户登录
api.userLogin(params)
// 用户的登出
通过以上的步骤，我们就实现了传统的、标准化的请求流程，这种请求使用方式是在前端项目中，我认为是最常见的代码书写方式，很简单、很规范、也很好理解，可以说结构特别清晰，我认为完全没有问题！因为我在项目中，大致也是这么使用的。
2 思考如何优化？
通过以上方式的实现，我们我们有没有想过，我们在不断的重复写一些代码，不断重复的写这些 API 声明、API 请求方法！如果是一个庞大的应用，API 有几百个也是有可能的。
试想一下：有多少个 API 地址，我们就会写多少个请求方法。如果将来需要改动，我们也要联动改动。那么在实际开发中可不可以优化呢？这些重复的方法声明可以省略掉吗？（重复的代码我不想写第二遍）
因此，本工具的理念就是做这些重复的劳动，我们只需要配置，其他的交给工具就可以了！
2.1 工具雏形
在 3.1.2 的代码步骤中，其实有一些是可以省略掉的，接口地址的定义属于配置文件，必须声明，因为每一个接口地址都是不同的。但是可以将请求方法的的构建省略，因为它们都具有相似性，可以使用函数将其生成。
基于以上这个思想，就有了该工具库的雏形，如下部分核心代码：
import request from '@/utils/request'
// 定义接口地址
const api = {
useLogin: '/api/user/login', // 用户登录
useLogout: '/api/user/logout' // 用户登出
// ...等等还有很多接口地址
}
const modules = {}
// 写一个函数自动注入
Object.keys(api).forEach(key => {
modules[key] = function (parameter, config = {}) {
const url = config.url || api[key]
const method = config.method || 'get'
const params = method === 'get' ? parameter : {}
const data = method === 'get' ? {} : parameter
return request({ ...{ url, method, params, data }, ...config })
}
})
export default modules
如下图所示，可以看到，通过运行代码，已经生成了请求类。
页面中使用方式如下：
import api from '@/api'
// 用户登录
api.userLogin(params)
// 用户的登出
api.userLogout()
// 一些开发的参数传递
api.userLogin(params, { method: 'POST' })
2.2 改进思考
其实以上的操作能够节省掉 80% 的代码，至少我们所有的方法声明都不用写，但是同时也有个问题，并不能适用于所有的方式！比如 RESTful 接口形式的请求。
可能有些前端开发对 RESTful 不太了解，这里简单说一下 RESTful 接口形式：
RESTful（Representational State Transfer）是一种基于资源的软件架构风格，它是一种设计网络应用程序的方式，特别适用于构建 Web 服务，它是一种基于 REST 原则设计的接口规范
说白了，RESTful 接口使用 HTTP 协议定义了一组常见的操作行为：GET（获取资源）、POST（创建资源）、PUT（更新资源）、DELETE（删除资源）等。通过合理地使用这些 HTTP 方法，可以实现对资源的增删改查操作。
说的再直白一点，就是接口地址是一样的，通过请求方式（GET/POST/PUT/DELETE）实现对资源的增删改查操作。
因此，假如我们有一些接口是这一种请求方式，通过 id 获取用户信息：/api/user/{id}，以上的方式却不太适合，我们可以进行加以改造：
import request from '@/utils/request'
// 定义接口地址
const api = {
user: '/api/user' // 用户模块
}
const modules = {}
// 改进函数，添加 append 参数，用
Object.keys(api).forEach(key => {
modules[key] = function (parameter, config = {}) {
const append = config.append || ''
const url = `${config.url || api[key]}${append}`
const method = config.method || 'GET'
const params = method === 'GET' ? parameter : {}
const data = method === 'GET' ? {} : parameter
return request({ ...{ url, method, params, data }, ...config })
}
})
// 其他不兼容的方法，可使用自定义方法
modules.other = function (params) {
return request({ url: '', params, method: 'GET' })
}
export default modules
再次运行代码，请求类已经包含了我们的自定义 other 方法
页面中使用方式如下：
import api from '@/api'
// 新增用户
api.user(params, { method: 'POST' })
// 删除用户
api.user({}, { method: 'DELETE', append: `/${userId}` })
// 修改用户
api.user(params, { method: 'PUT' })
// 查询用户
api.user(params, { method: 'GET', append: `/${userId}` })
// 其他不兼容的方法，使用自定义方法
api.other(params)
以上的代码其实就是 Flyit 工具库中 FlyHttp 模块的核心思想，后面的改进优化思路也都是依据请求框架来不断进步的，我整理了一下思路和代码，现已经将它发布到 npm，接下来我们看看具体如何使用吧！