前言
如果你做的是比较大型的项目，有非常非常多的api需要做配置和维护，那么下面这篇文章可能就可以帮助你啦～
思想架构
用的是promise机制处理，将一次请求分成了三段：
页面 —— Vuex —— axios实例
其中，Vuex调用axios实例时还会用到api配置文件。
api配置文件的作用之后会说明。
整个流程：页面触发Vuex的actions，对应把需要的参数传过去，Vuex再调用axios实例，把对应的api配置和参数传到axios实例：
- 对于统一的http错误以及业务错误可以在
axios实例做拦截处理。 - 对于数据的改动在Vuex做处理【可能对应有些视图会发生更新】
- 对应页面本身的一些变量的操作。
具体实现
构造两个axios实例：serverIn和serverOut，我把这两个实例这样处理：
Vue.prototype.$ajax = serviceIn
Vue.prototype.$axios = serviceOut
其中$axios部分不说，不过我把作者的response删掉了……
考虑到有时候还是需要用到headers之类的信息。
来看看serviceIn如何使用：
this.$ajax({
...api['login'],
data
}).then...
那这里一定很好奇api['login']是什么吧？
export default {
login: {
url: baseApi + '/login',
method: 'post',
contentType: 'normal'
}
}
这是我api文件下一个app里的部分代码：
- baseApi是基础接口，相同的一类可以统一配置到一起；
- contentType是我自定义的，在request做对应的处理
然后把关于这个接口所有和业务无关的但是和服务器请求有关的配置都可以丢到这。
- 接口地址
- method方法
- contentType
- responseType
- ...
我这样做的目的是把与后端对接的api文档通过配置表的方式结合起来，作为前端配置和查阅使用。
serverIn
对应的是公司内的请求，可以和后端商量定义好一些规范：
request
- 主要是Content-Type的定义，如果有多种……
- axios在data方面需要做一层处理：
const qs = require('querystring')
// request interceptor
serviceIn.interceptors.request.use(config => {
// 如果是'application/x-www-form-urlencoded'，需要做特殊的处理
config.headers['Content-Type'] = 'application/x-www-form-urlencoded'
config.data = qs.stringify({
...config.data
})
}, error =>{}
reponse
- HTTP状态错误码的错误规范，例如服务器更新
- 业务范围内的错误码，比如500提示错误信息，501在500的基础上做一些特殊的业务操作。
- 确定传输文件方式，比如如果用blob，可以在里面封装一个“另存为”，自动下载。
serverOut
对应的外部，第三方的接口，这里就不多说啦～
