上篇文章: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
,接下来我们看看具体如何使用吧!