論vue項目api相關代碼的組織方式

論vue項目api相關代碼的組織方式

看了下項目組同事的代碼，發現不一樣項目有不一樣的組織版本

版本一：

├─apis
│      a.api.js
│      b.api.js
│      b.api.js
│      d.api.js

每一個api文件裏都是這樣的代碼

// d.api.js
import axios from '@/utils/http'

export function editUser (Param) {
    return axios.post('url1', {
        ...Param
    })
}
export function deleteUser (Param) {
    return axios.post('url2', {
        ...Param
    })
}
// 調用方式以下
import {editUser} from '@/apis/d.api.js'

這種方法的缺點：

1. 新增一個藉口就新增一個方法
2. 任何須要調用藉口的地方都須要引入
3. api文件裏只有url和函數名不同,其餘都同樣,應該封裝到一塊兒
4. 查看全部接口需一個一個函數去看,麻煩

版本二：
乾脆不把api統一到一塊兒，把axios掛載到vue對象上只在須要的地方寫

this.$axios.post(url,params).then()

這種方法缺點：

1. 若是修改url路徑,須要全局搜索替換改動地方較多
2. 沒法查看全部接口，不便於全局掌控

版本三:

// apis/index.js
// 把全部api的url統一在一塊兒並掛在到vue對象上
// 全部接口都在一個文件裏會比較大
// 能夠按功能模塊分組編寫
let ENV = {
    name1: 'url1', 
    // 用戶相關接口
    name2: 'url2', 
    // 積分相關接口
    name3: 'url3',
    // 產品相關接口
    name4: 'url4', 
}
export default ENV

// src/main.js
import api from '@/apis/index.js'
Vue.prototype.$api = api

//須要調用接口的js文件
this.$axios.post(this.$api.name1,params).then()

缺點：

1. 暫時沒想到

優勢:

1. 更改url時只須要改動一個地方
2. 能夠在一個地方查看全部接口