記一次封裝Axios的經歷
前言
前端開發中，若是頁面須要與後臺接口交互，而且無刷新頁面，那麼須要藉助一下Ajax的http庫來完成與後臺數據接口的對接工做。在jQuery很盛行的時候，咱們會使用$.ajax()，如今，可選擇的就更多，例如：SuperAgent、Axios、Fetch…等等。有了這些http庫，咱們不在須要關注太多與ajax底層相關的細節的問題。不少時候和場景下，只須要關注如何構建一個request以及如何處理一個response便可，但即使這些http庫已經在必定程度上簡化了咱們的開發工做，咱們仍然須要針對項目的實際須要，團隊內部技術規範對這些http庫進行封裝，進而優化咱們的開發效率。javascript
本文將結合咱們團隊使用的一個http庫Axios和咱們團隊開發工程的一些場景，分享咱們前端團隊對http庫進行封裝的經歷。前端
對http庫進行基本的封裝
服務端URL接口的定義
以用戶管理模塊爲例。對於用戶管理模塊，服務端一般會定義以下接口：vue
GET /users?page=0&size=20- 獲取用戶信息的分頁列表GET /users/all- 獲取全部的用戶信息列表GET /users/:id- 獲取指定id的用戶信息POST /users application/x-www-form-urlencoded- 建立用戶PUT /users/:id application/x-www-form-urlencoded- 更新指定id的用戶信息DELETE /users/:id刪除指定id的用戶信息
經過以上定義，不難發現這些都是基於RESTful標準進行定義的接口。java
將接口進行模塊化封裝
針對這樣一個用戶管理模塊，咱們首先須要作的就是定義一個用戶管理模塊類。react
// UserManager.js
import axios from 'axios'
class UserManager {
constructor() {
this.$http = axios.create({
baseUrl: 'https://api.forcs.com' // 固然，這個地址是虛擬的
})
// 修改POST和PUT請求默認的Content-Type，根據本身項目後端的定義而定，不必定須要
this.dataMethodDefaults = {
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
transformRequest: [function (data) {
return qs.stringify(data)
}]
}
}
}
export default new UserManager() // 單例模塊
複製代碼
在UserManager的構造函數中，咱們設置了一些請求的公共參數，好比接口的baseUrl，這樣後面在發起請求的時候，URL只須要使用相對路徑便可。與此同時，咱們還調整了POST請求和PUT請求默認的Content-Type。Axios默認是application/json，咱們根據後端接口的定義，將其調整成了表單類型application/x-www-form-urlencoded。最後，藉助ES6模塊化的特性，咱們將UserManager單例化。webpack
實際的場景中，一套符合行業標準的後端接口規範要比這複雜得多。因爲這些內容不是本文討論的重點，因此簡化了。ios
接着，給UserManager添加調用接口的方法。git
import axios from 'axios'
import qs from 'query-string'
class UserManager {
constructor() {
this.$http = axios.create({
baseUrl: 'https://api.forcs.com'
})
this.dataMethodDefaults = {
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
transformRequest: [function (data) {
return qs.stringify(data)
}]
}
}
getUsersPageableList (page = 0, size = 20) {
return this.$http.get(`/users?page=${page}&size=${size}`)
}
getUsersFullList () {
return this.$http.get('/users/all')
}
getUser (id) {
if (!id) {
return Promise.reject(new Error(`getUser：id(${id})無效`))
}
return this.$http.get(`/users/${id}`)
}
createUser (data = {}) {
if (!data || !Object.keys(data).length) {
return Promise.reject(new Error('createUser：提交的數據無效'))
}
return this.$http.post('/users', data, { ...this.dataMethodDefaults })
}
updateUser (id, update = {}) {
if (!update || !Object.keys(update).length) {
return Promise.reject(new Error('updateUser：提交的數據無效'))
}
return this.$http.put(`/users/${id}`, update, { ...this.dataMethodDefaults })
}
deleteUser (id) {
if (!id) {
return Promise.reject(new Error(`deleteUser：id(${id})無效`))
}
return this.$http.delete(`/users/${id}`)
}
}
export default new UserManager()
複製代碼
新增的方法沒有什麼特別的地方，一目瞭然，就是經過Axios執行http請求調用服務端的接口。值得注意的是，在getUser()、createUser()、updateUser()、deleteUser()這四個方法中，咱們對參數進行了簡單的驗證，固然，實際的場景會比範例代碼的更加複雜些，其實參數驗證不是重點，關鍵在於驗證的if語句塊中，return的是一個Promise對象，這是爲了和Axios的API保持一致。es6
前端調用封裝的方法
通過這樣封裝後，前端頁面與服務端交互就變得簡單多了。下面以Vue版本的前端代碼爲例github
<!-- src/components/UserManager.vue -->
<template>
<!-- 模板代碼能夠忽略 -->
</template>
<script>
import userManager from '../services/UserManager'
export default {
data () {
return {
userList: [],
currentPage: 0,
currentPageSize: 20,
formData: {
account: '',
nickname: '',
email: ''
}
}
},
_getUserList () {
userManager.getUser(this.currentPage, this.currentPageSize)
.then(response => {
this.userList = response.data
}).catch(err => {
console.error(err.message)
})
},
mounted () {
// 加載頁面的時候，獲取用戶列表
this._getUserList()
},
handleCreateUser () {
// 提交建立用戶的表單
userManager.createUser({ ...this.formData })
.then(response => {
// 刷新列表
this._getUserList()
}).catch(err => {
console.error(err.message)
})
}
}
</script>
複製代碼
固然，相似的js代碼在React版本的前端頁面上也是適用的。
// src/components/UserList.js
import React from 'react'
import userManager from '../servers/UserManager'
class UserManager extends React.Compnent {
constructor (props) {
super(props)
this.state.userList = []
this.handleCreateUser = this.handleCreateUser.bind(this)
}
_getUserList () {
userManager.getUser(this.currentPage, this.currentPageSize)
.then(response => {
this.setState({ userList: userList = response.data })
}).catch(err => {
console.error(err.message)
})
}
componentDidMount () {
this._getUserList()
}
handleCreateUser (data) {
userManager.createUser({ ...data })
.then(response => {
this._getUserList()
}).catch(err => {
console.error(err.message)
})
}
render () {
// 模板代碼就能夠忽略了
return (/* ...... */)
}
}
export default UserManager
複製代碼
爲了節省篇幅，後面就再也不展現前端頁面上調用封裝模塊的代碼了。
ok，接口用起來很方便，封裝到這一步感受彷佛沒啥毛病。但是，一個APP怎麼可能就這麼些接口呢，它會涉及到若干個接口，而不一樣的接口可能歸類在不一樣的模塊。就拿咱們的後臺項目來講，內容管理模塊就分爲單片管理和劇集管理，劇集管理即包括劇集實體自身的管理，也包括對單片進行打包的管理，因此，後臺對內容管理模塊的接口定義以下：
單片管理：
GET /videos?page=0&size=20GET /videos/allGET /videos/:idPOST /videos application/x-www-form-urlencodedPUT /videos/:id application/x-www-form-urlencodedDELETE /videos/:id
劇集管理：
GET /episodes?page=0&size=20GET /episodes/allGET /episodes/:idPOST /episodes application/x-www-form-urlencodedPUT /episodes/:id application/x-www-form-urlencodedDELETE /episodes/:id
篇幅關係，就不列出全部的接口了。能夠看到接口依然是按照RESTful標準來定義的。按照以前說的作法，咱們能夠當即對這些接口進行封裝。
定義一個單品管理的模塊類VideoManager
// VideoManager.js
import axios from 'axios'
import qs from 'query-string'
class VideoManager {
constructor () {
this.$http = axios.create({
baseUrl: 'https://api.forcs.com'
})
this.dataMethodDefaults = {
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
transformRequest: [function (data) {
return qs.stringify(data)
}]
}
}
getVideosPageableList (page = 0, size = 20) {
return this.$http.get(`/videos?page=${page}&size=${size}`)
}
getVideosFullList () {
return this.$http.get('/videos/all')
}
getVideo (id) {
if (!id) {
return Promise.reject(new Error(`getVideo：id(${id})無效`))
}
return this.$http.get(`/videos/${id}`)
}
// ... 篇幅緣由，後面的接口省略
}
export default new VideoManager()
複製代碼
以及劇集管理的模塊類EpisodeManager.js
//EpisodeManager.js
import axios from 'axios'
import qs from 'query-string'
class EpisodeManager {
constructor () {
this.$http = axios.create({
baseUrl: 'https://api.forcs.com'
})
this.dataMethodDefaults = {
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
transformRequest: [function (data) {
return qs.stringify(data)
}]
}
}
getEpisodesPageableList (page = 0, size = 20) {
return this.$http.get(`/episodes?page=${page}&size=${size}`)
}
getEpisodesFullList () {
return this.$http.get('/episodes/all')
}
getEpisode (id) {
if (!id) {
return Promise.reject(new Error(`getEpisode：id(${id})無效`))
}
return this.$http.get(`/episodes/${id}`)
}
// ... 篇幅緣由，後面的接口省略
}
export default new EpisodeManager()
複製代碼
發現問題了嗎？存在重複的代碼，會給後期的維護埋下隱患。編程原則中，有一個很著名的原則：DRY，翻譯過來就是要儘量的避免重複的代碼。在靈活的前端開發中，要更加留意這條原則，重複的代碼越多，維護的成本越大，靈活度和健壯性也隨之下降。想一想要是大型的APP涉及到的模塊有數十個以上，每一個模塊都擼一遍這樣的代碼，若是後期公共屬性有啥調整的話，這樣的改動簡直就是個災難！
爲了提高代碼的複用性，靈活度，減小重複的代碼，應該怎麼作呢？若是瞭解OOP的話，你應該能夠很快想出對——定義一個父類，抽離公共部分。
讓封裝的模塊更具有複用性
使用繼承的方式進行重構
定義一個父類BaseModule，將代碼公共的部分都放到這個父類中。
// BaseModule.js
import axios from 'axios'
import qs from 'query-string'
class BaseModule {
constructor () {
this.$http = axios.create({
baseUrl: 'https://api.forcs.com'
})
this.dataMethodDefaults = {
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
transformRequest: [function (data) {
return qs.stringify(data)
}]
}
}
get (url, config = {}) {
return this.$http.get(url, config)
}
post (url, data = undefined, config = {}) {
return this.$http.post(url, data, { ...this.dataMethodDefaults, ...config })
}
put (url, data = undefined, config = {}) {
return this.$http.put(url, data, { ...this.dataMethodDefaults, ...config })
}
delete (url, config = {}) {
return this.$http.delete(url, config)
}
}
export default BaseModule
複製代碼
而後讓UserManager、VideoManager、EpisodeManager都繼承自這個BaseModule，移除重複的代碼。
UserManager.js
+ import BaseModule from './BaseModule'
- import axios from 'axios'
- import qs from 'query-string'
+ class UserManager extends BaseModule {
- class UserManager {
constructor() {
+ super()
- this.$http = axios.create({
- baseUrl: 'https://api.forcs.com'
- })
- this.dataMethodDefaults = {
- headers: {
- 'Content-Type': 'application/x-www-form-urlencoded'
- },
- transformRequest: [function (data) {
- return qs.stringify(data)
- }]
- }
}
getUsersPageableList (page = 0, size = 20) {
+ return this.get(`/users?page=${page}&size=${size}`)
- return this.$http.get(`/users?page=${page}&size=${size}`)
}
getUsersFullList () {
+ return this.get('/users/all')
- return this.$http.get('/users/all')
}
getUser (id) {
if (!id) {
return Promise.reject(new Error(`getUser：id(${id})無效`))
}
+ return this.get(`/users/${id}`)
- return this.$http.get(`/users/${id}`)
}
// ......
}
export default new UserManager()
複製代碼
VideoManager.js
+ import BaseModule from './BaseModule'
- import axios from 'axios'
- import qs from 'query-string'
+ class VideoManager extends BaseModule {
- class VideoManager {
constructor () {
+ super()
- this.$http = axios.create({
- baseUrl: 'https://api.forcs.com'
- })
- this.dataMethodDefaults = {
- headers: {
- 'Content-Type': 'application/x-www-form-urlencoded'
- },
- transformRequest: [function (data) {
- return qs.stringify(data)
- }]
- }
}
getVideosPageableList (page = 0, size = 20) {
+ return this.get(`/videos?page=${page}&size=${size}`)
- return this.$http.get(`/videos?page=${page}&size=${size}`)
}
getVideosFullList () {
+ return this.get('/videos/all')
- return this.$http.get('/videos/all')
}
getVideo (id) {
if (!id) {
return Promise.reject(new Error(`getVideo：id(${id})無效`))
}
+ return this.get(`/videos/${id}`)
- return this.$http.get(`/videos/${id}`)
}
// ......
}
export default new VideoManager()
複製代碼
EpisodeManager.js
+ import BaseModule from './BaseModule'
- import axios from 'axios'
- import qs from 'query-string'
+ class EpisodeManager extends BaseModule {
- class EpisodeManager {
constructor () {
+ super()
- this.$http = axios.create({
- baseUrl: 'https://api.forcs.com'
- })
- this.dataMethodDefaults = {
- headers: {
- 'Content-Type': 'application/x-www-form-urlencoded'
- },
- transformRequest: [function (data) {
- return qs.stringify(data)
- }]
- }
}
getEpisodesPageableList (page = 0, size = 20) {
+ return this.get(`/episodes?page=${page}&size=${size}`)
- return this.$http.get(`/episodes?page=${page}&size=${size}`)
}
getEpisodesFullList () {
+ return this.get('/episodes/all')
- return this.$http.get('/episodes/all')
}
getEpisode (id) {
if (!id) {
return Promise.reject(new Error(`getEpisode：id(${id})無效`))
}
+ return this.get(`/episodes/${id}`)
- return this.$http.get(`/episodes/${id}`)
}
// ... 篇幅緣由，後面的接口省略
}
export default new EpisodeManager()
複製代碼
利用OOP的繼承特性，將公共代碼抽離到父類中，使得封裝模塊接口的代碼獲得必定程度的簡化，之後若是接口的公共部分的默認屬性有何變更，只須要維護BaseModule便可。若是你對BaseModule有留意的話，應該會注意到，BaseModule也不徹底將公共部分隱藏在自身當中。同時，BaseModule還對Axios對象的代理方法（axios.get()、axios.post()、axios.put()、axios.delete()）進行了包裝，從而將Axios內聚在自身內部，減小子類的依賴層級。對於子類，再也不須要關心Axios對象，只須要關心父類提供的方法和部分屬性便可。這樣作，一方面提高了父類的複用性，另外一方面也使得子類能夠更加好對父類進行擴展，同時又不影響到其餘子類。
對於通常場景，封裝到這裏，此役也算是能夠告捷，終於能夠去衝杯咖啡小歇一會咯。不過，公司還沒跨，事情怎麼可能完呢……
BaseModule的問題
過了一週後，新項目啓動，這個項目對接的是另外一個後端團隊的接口。大致上還好，接口命名風格依然基本跟着RESTful的標準走，但是，請求地址的域名換了，請求頭的Content-Type也和以前團隊定義的不同，這個後端團隊用的是application/json。
固然，實際上不一樣的後端團隊定義的接口，差別未必會這麼小:(
面對這種場景，咱們的第一反應多是：好擼，把以前項目的BaseModule複製到如今的項目中，調整一下就行了。
import axios from 'axios'
import qs from 'query-string'
class BaseModule {
constructor () {
this.$http = axios.create({
- baseUrl: 'https://api.forcs.com'
+ baseUrl: 'https://api2.forcs.com'
})
- this.dataMethodDefaults = {
- headers: {
- 'Content-Type': 'application/x-www-form-urlencoded'
- },
- transformRequest: [function (data) {
- return qs.stringify(data)
- }]
- }
}
get (url, config = {}) {
return this.$http.get(url, config)
}
post (url, data = undefined, config = {}) {
- return this.$http.post(url, data, { ...this.dataMethodDefaults, ...config })
+ return this.$http.post(url, data, config)
}
put (url, data = undefined, config = {}) {
- return this.$http.post(url, data, { ...this.dataMethodDefaults, ...config })
+ return this.$http.put(url, data, config)
}
delete (url, config = {}) {
return this.$http.delete(url, config)
}
}
export default BaseModule
複製代碼
因爲Axios默認POST和PUT請求Header的Content-Type是application/json，因此只須要將以前設置Content-Type的代碼移除便可。接着，就能夠喝着咖啡，聽着歌，愉快的封裝接口對接數據了！
認真回想一下，這樣作其實又了咱們以前提到一個問題：重複的代碼。你可能認爲，反正不是一個項目的，代碼獨立維護，因此這樣也不打緊。我從客觀的角度認爲，對於一些小項目或者小團隊，這樣作的確沒啥毛病，但若是，我是說若是，項目愈來愈多了，這樣每一個項目複製一套代碼真的好嗎？假如哪天后端團隊作了統一規範，全部接口的請求頭都按照一套規範來設置，其實以前的代碼都得逐一調整？個人天，這得多大工做量。總之，重複的代碼就是個坑！
應對這種狀況，怎麼破？
讓封裝的模塊更具有通用性
在面向對象編程的原則中，有這麼一條：開閉原則。即對擴展開發，對修改關閉。根據這條原則，我想到的一個方案，就是給封裝的BaseModule提供對外設置的選項，就像jQuery的大多數插件那樣，工廠方法中都會提供一個options對象參數，方便外層調整插件的部分屬性。咱們也能夠對BaseModule進行一些改造，讓它更靈活，更易於擴展。
對BaseModule進行重構
接下來須要對以前的BaseModule進行重構，讓它更具有通用性。
import axios from 'axios'
import qs from 'query-string'
function isEmptyObject (obj) {
return !obj || !Object.keys(obj).length
}
// 清理headers中不須要的屬性
function clearUpHeaders (headers) {
[
'common',
'get',
'post',
'put',
'delete',
'patch',
'options',
'head'
].forEach(prop => headers[prop] && delete headers[prop])
return headers
}
// 組合請求方法的headers
// headers = default <= common <= method <= extra
function resolveHeaders (method, defaults = {}, extras = {}) {
method = method && method.toLowerCase()
// check method參數的合法性
if (!/^(get|post|put|delete|patch|options|head)$/.test(method)) {
throw new Error(`method:${method}不是合法的請求方法`)
}
const headers = { ...defaults }
const commonHeaders = headers.common || {}
const headersForMethod = headers[method] || {}
return _clearUpHeaders({
...headers,
...commonHeaders,
...headersForMethod,
...extras
})
}
// 組合請求方法的config
// config = default <= extra
function resolveConfig (method, defaults = {}, extras = {}) {
if (isEmptyObject(defaults) && isEmptyObject(extras)) {
return {}
}
return {
...defaults,
...extras,
resolveHeaders(method, defaults.headers, extras.headers)
}
}
class HttpClientModule {
constructor (options = {}) {
const defaultHeaders = options.headers || {}
if (options.headers) {
delete options.headers
}
const defaultOptions = {
baseUrl: 'https://api.forcs.com',
transformRequest: [function (data, headers) {
if (headers['Content-Type'] === 'application/x-www-form-urlencoded') {
// 針對application/x-www-form-urlencoded對data進行序列化
return qs.stringify(data)
} else {
return data
}
}]
}
this.defaultConfig = {
headers: {
'Content-Type': 'application/x-www-form-urlencoded',
...defaultHeaders
}
}
this.$http = axios.create({ ...defaultOptions, ...options })
}
get (url, config = {}) {
return new Promise((resolve) => {
resolve(this.$http.get(url, resolveConfig(
'get', this.defaultConfig, config)))
})
}
post (url, data = undefined, config = {}) {
return new Promise((resolve) => {
resolve(this.$http.post(url, data, resolveConfig(
'post', this.defaultConfig, config)))
})
}
put (url, data = undefined, config = {}) {
return new Promise((resolve) => {
resolve(this.$http.put(url, data, resolveConfig(
'put', this.defaultConfig, config)))
})
}
delete (url, config = {}) {
return new Promise((resolve) => {
resolve(this.$http.delete(url, resolveConfig(
'delete', this.defaultConfig, config)))
})
}
}
// 導出工廠方法
export function createHttpClient (options, defaults) {
return new HttpClientModule(options, defaults)
}
// 默認導出模塊對象
export default HttpClientModule // import
複製代碼
通過重構的BaseModule已經面目全非，模塊的名稱也換成了更加通用的叫法：HttpClientModule。HttpClientModule的構造函數提供了一個options參數，爲了減小模塊的學習成本，options基本沿用了Axios的Request Config定義的結構體。惟獨有一點不一樣，就是對options的headers屬性處理。
這裏須要多說一下，看似完美的Axios存在一個比較嚴重，但至今還沒修復的bug，就是經過defaults屬性設置headers是不起做用的，必須在執行請求操做（調用request()、get()、post()…等請求方法）時，經過方法的config參數設置header纔會生效。爲了規避這個特性的bug，我在HttpClientModule這個模塊中，按照Axios的API設計，本身手動實現了相似的features。既能夠經過common屬性設置公共的header，也能夠以請求方法名（get、post、put…等）做爲屬性名來給特定請求方法的請求設置默認的header。大概像下面這樣：
const options = {
// ...
headers: {
// 設置公共的header
common: {
Authorization: AUTH_TOKEN
},
// 爲post和put請求設置請求時的Content-Type
post: {
'Content-Type': 'application/x-www-form-urlencoded'
},
put: {
'Content-Type': 'application/x-www-form-urlencoded'
}
}
}
const httpClient = new HttpClientModule(options)
複製代碼
獨立發佈重構的封裝模塊
咱們能夠爲HttpClientModule單首創建一個npm項目，給它取一個名詞，例如httpclient-module。取名前最好先上npmjs上查一下名稱是否已經被其它模塊使用了，儘可能保持名稱的惟一性。而後經過webpack、rollup、parcel等構建工具進行打包，發佈到npmjs上。固然，若是代碼中涉及到私有的配置信息，也能夠本身搭建一個npm私服倉庫，而後布到私服上。這樣，就能夠經過npm install命令直接將模塊安裝到咱們的項目中來使用了。安裝模塊能夠經過以下命令：
npm install httpclient-module --save
# or
npm i httpclient-module -S
複製代碼
對業務接口層的模塊進行調整
還記得前面針對業務層定義的UserManager、VideoManager以及EpisodeManager嗎，他們都繼承自BaseModule，但爲了讓父類BaseModule更具通用性，咱們以及將它進行了重構，而且換了個名稱進行了獨立發佈，那麼這幾個業務層的manager模塊應該如何使用這個通過重構的模塊HttpClientModule呢？
由於那些manager模塊都繼承自父類BaseModule，咱們只須要對BaseModule進行調整便可。
- import axios from 'axios'
- import qs from 'query-string'
+ import { createHttpClient } from 'httpclient-module'
+ const P_CONTENT_TYPE = 'application/x-www-form-urlencoded'
class BaseModule {
constructor () {
- this.$http = axios.create({
- baseUrl: 'https://api.forcs.com'
- })
- this.dataMethodDefaults = {
- headers: {
- 'Content-Type': 'application/x-www-form-urlencoded'
- },
- transformRequest: [function (data) {
- return qs.stringify(data)
- }]
- }
+ this.$http = createHttpClient({
+ headers: {
+ post: { 'Content-Type': P_CONTENT_TYPE },
+ put: { 'Content-Type': P_CONTENT_TYPE }
+ }
+ })
}
get (url, config = {}) {
return this.$http.get(url, config)
}
post (url, data = undefined, config = {}) {
- return this.$http.post(url, data, { ...this.dataMethodDefaults, ...config })
+ return this.$http.post(url, data, config)
}
put (url, data = undefined, config = {}) {
- return this.$http.put(url, data, { ...this.dataMethodDefaults, ...config })
+ return this.$http.put(url, data, config)
}
delete (url, config = {}) {
return this.$http.delete(url, config)
}
}
export default BaseModule
複製代碼
本質上就是用本身封裝的httpclient-module替換了原來的Axios。這樣有什麼好處呢？
httpclient-module能夠認爲是Axios與業務接口層之間的適配器。將Axios封裝到httpclient-module，下降了前端項目對第三方庫的依賴。前面有提到Axios是存在一些比較明顯的bug的，通過這層封裝，咱們能夠下降bug對項目的影響，只須要維護httpclient-module，就能夠規避掉第三方bug帶來的影響。若是之後發現有更好的http庫，須要替換掉Axios，只須要升級httpclient-module就能夠了。對於業務層，不須要作太大的調整。
有了httpclient-module這層適配器，也給團隊作技術統一化規範帶來方便。假如之後團隊的接口規範作了調整，好比接口域名切換到https，請求頭認證作統一調整，或者請求頭須要增減其餘參數，也只須要更新httpclient-module就好。若是不是團隊作統一調整，而是個別項目，也只須要調整BaseModule，修改一下傳遞給httpclient-module的options參數便可。
讓封裝的模塊提升咱們開發效率
用httpclient-module愉快的工做了一段時間後，咱們又遇到了新的問題。
隨着項目迭代，前端加入的業務功能愈來愈多，須要對接後臺的業務接口也逐漸增多。好比新增一個內容供應商管理模塊，咱們就須要爲此建立一個CPManager，而後添加調用接口請求的方法，新增一個內容標籤管理模塊，就須要定義一個TagManager，而後添加調用接口請求的方法。像下面這樣的代碼。
新增的內容供應商管理模塊：
// CPManager.js
// ...
class CPManager extends BaseModule {
constructor () { /* ... */ }
createCp (data) { /* ... */ }
getCpPageableList (page = 0, size = 20) { /* ... */ }
getCpFullList () { /* ... */ }
getCp (id) { /* ... */ }
updateCp (id, update) { /* ... */ }
deleteCp (id) { /* ... */ }
// ...
}
複製代碼
內容標籤管理模塊：
// TagManager.js
// ...
class TagManager extends BaseModule {
constructor () { /* ... */ }
createTag (data) { /* ... */ }
getTagPageableList (page = 0, size = 20) { /* ... */ }
getTagFullList () { /* ... */ }
getTag (id) { /* ... */ }
updateTag (id, update) { /* ... */ }
deleteTag (id) { /* ... */ }
// ...
}
複製代碼
新增的模塊遠不止這些，咱們發現，代碼中存在不少重複的地方，好比createXXX()、getXXX()、updateXXX()、deleteXXX()，分別對應的都是模塊下的CRUD接口，並且若是業務接口沒有太特殊的場景時，定義一個接口，僅僅就是爲了封裝一個調用。
// ...
class TagManager extends BaseModule {
// ...
createTag (data) {
// 定義createTag()方法，就是爲了簡化/tags的POST請求
return this.$http.post('/tags', data)
}
// ...
}
複製代碼
咱們以爲這些重複的工做是能夠簡化掉的。根據方法語義化命名的習慣，建立資源的方法咱們會以create做爲前綴，對應執行POST請求。更新資源使用update做爲方法名的前綴，對應執行PUT請求。獲取資源或者資源列表，方法名以get開頭，對應GET請求。刪除資源，則用delete開頭，對應DELETE請求。以下表所示：
| 方法名前綴 | 功能 | 請求方法 | 接口 |
|---|---|---|---|
| create | 建立資源 | POST | /resources |
| get | 獲取資源 | GET | /resources/:id、/resources、/resources/all |
| update | 更新資源 | PUT | /resources/:id |
| delete | 刪除資源 | DELETE | /resources/:id |
按照這個約定，咱們團隊想，既然方法的前綴、請求方法和URL接口三者能夠存在一一對應的關係，那麼能不能經過Key -> Value的方式自動化的生成與URL請求綁定好了的方法呢？
例如TagManager，咱們但願經過相似下面的代碼進行建立。
// TagManager.js
const urls = {
createTag: '/tags',
updateTag: '/tags/:id',
getTag: '/tags/:id',
getTagPageableList: '/tags',
getTagFullList: '/tags/all',
deleteTag: '/tags/:id'
}
export default moduleCreator(urls)
複製代碼
而後在UI層能夠直接調用建立好的模塊方法。
// TagManager.vue
<script>
import tagManager from './service/TagManager.js'
// ...
export default {
data () {
return {
tagList: [],
page: 0,
size: 20,
// ...
}
},
// ...
_refresh () {
const { page, size } = this
// GET /tags?page=[page]&size=[size]
tagManager.getTagPageableList({ page, size })
.then(resolved => this.tagList = resolved.data)
},
mounted () {
this._refresh()
},
handleCreate (data) {
// POST /tags
tagManager.createTag({ ...data })
.then(_ => this._refresh())
.catch(err => console.error(err.message))
},
handleUpdate (id, update) {
// PUT /tags/:id
tagManager.updateTag({ id }, { ...update })
.then(_ => this._refresh())
.catch(err => console.error(err.message))
},
handleDelete (id) {
// DELETE /tags/:id
tagManager.deleteTag({ id })
.then(_ => this._refresh())
.catch(err => console.error(err.message))
},
// ...
}
</script>
複製代碼
這樣在前端定義一個業務接口的模塊是否是方便多了：）並且，有沒有注意到，咱們對接口的傳參也作了調整。不管是URL的路徑變量仍是查詢參數，咱們均可以經過對象化的方式進行傳遞。這種統一參數類型的調整，簡化了接口的學習成本，自動生成的方法都是經過對象化的方式將參數綁定到接口當中。
在RESTful標準的接口中，接口的URL可能會存在兩種參數，路徑變量（Path Variables）和查詢參數（Query Argument）。
- 路徑變量：就是URL中映射到指定資源所涉及的變量，好比/resources/:id，這裏的:id，指的就是資源id，操做不一樣的資源時，URL中:id這段路徑也會不一樣。/resources/1，/resources/2…等
- 查詢參數：指的是URL中的query參數，一般就是GET請求或者DELETE請求的URL中問號後面那段，好比/resources?page=0&size=20，page和size就是查詢參數
先來一波實現的思路
首先對自動生成的與URL綁定的模塊方法進行設計。
// GET, DELETE
methodName ([params|querys:PlainObject, [querys|config:PlainObject, [config:PlainObject]]]) => :Promise
// POST, PUT
methodName ([params|data:PlainObject, [data|config:PlainObject, [config:PlainObject]]]) => :Promise
複製代碼
這是一段僞代碼。params表示路徑參數對象，querys表示GET或者DELETE請求的查詢參數對象，data表示POST或者PUT請求提交的數據對象，大概要傳達的意思是：
- 自動生成的方法，會接受3個類型爲
Plain Object的參數，參數都是可選的，返回一個Promise對象。 - 當給方法傳遞三個參數對象的時候，參數依次是路徑變量對象，查詢參數對象或者數據對象，兼容
AxiosAPI的config對象。
下面用一個GET請求和一個PUT請求進行圖解示意，先看看GET請求：
下面是PUT請求：
- 當傳遞兩個參數時，若是URL接口不帶路徑變量，那麼第一個參數是查詢參數對象（
GET方法或者DELETE方法）或者數據對象（POST方法或者PUT方法），第二個是config對象。若是URL接口帶有路徑變量，那麼第一個參數就表示路徑變量對象，第二個參數是查詢參數對象或者數據對象。
好比下面兩個GET方法的URL接口，左邊這個不帶路徑變量，右邊的帶有路徑變量:id。左邊的，假設與URL接口綁定的方法名是getTagPageableList，當咱們調用方式只穿兩個參數，那麼第一個參數會轉換成查詢參數的格式key1=value1&key2=value2&...&keyn=valuen，第二個參數則至關於Axios的config對象。右邊的，由於URL接口中帶有路徑變量:id，那麼調用綁定URL接口的方法getTagById並傳了兩個參數時，第一個參數對象被根據key替換掉URL接口中的路徑變量，第二個參數則會被做爲查詢參數使用。
POST方法和PUT方法的請求也是相似，只是將查詢參數替換成了提交的數據。
- 當只傳遞一個參數時，若是接口URL不帶路徑變量，那麼這個參數就是查詢參數對象或者數據對象，若是接口URL帶有路徑變量，那麼這個參數對象就會映射到路徑變量中。
兩個GET請求：
一個POST請求和一個PUT請求：
將思路轉換成實現的代碼
在httpclient-module中實現功能。
// ...
/* 請求方法與模塊方法名的映射關係對象 * key -> 請求方法 * value -> pattern：方法名的正則表達式，sendData：表示是不是POST，PUT或者PATCH方法 */
const methodPatternMapper = {
get: { pattern: '^(get)\\w+$' },
post: { pattern: '^(create)\\w+$', sendData: true },
put: { pattern: '^(update)\\w+$', sendData: true },
delete: { pattern: '^(delete)\\w+$' }
}
// 輔助方法，判斷是不是函數
const isFunc = function (o) {
return typeof o === 'function'
}
// 輔助方法，判斷是不是plain object
// 這個方法相對簡單，若是想看更加嚴謹的實現，能夠參考lodash的源碼
const isObject = function (o) {
return Object.prototype.toString.call(o) === '[object Object]'
}
/* * 將http請求綁定到模塊方法中 * * @param method 請求方法 * @param moduleInstance 模塊實例對象或者模塊類的原型對象 * @param shouldSendData 表示是不是POST，或者PUT這類請求方法 * * @return Axios請求api返回的Promise對象 */
function bindModuleMethod(method, moduleInstance, shouldSendData) {
return function (url, args, config = {}) {
return new Promise(function (resolve, reject) {
let p = undefined
config = { ...config, url, method }
if (args) {
shouldSendData ?
config.data = args :
config.url = `${config.url}?${qs.stringify(args)}`
}
moduleInstance.$http.request(config)
.then(response => resolve(response))
.catch((error) => reject(error))
})
}
}
/* * 根據定義的模塊方法名稱，經過methodPatternMapper轉換成綁定URL的模塊方法 * * @param moduleInstance 模塊實例對象或者模塊類的原型對象 * @param name 模塊方法名稱 * * @return Function 綁定的模塊方法 * @throw 方法名稱和請求方法必須一一匹配 * 若是發現匹配到的方法不止1個或者沒有，則會拋出異常 */
function resolveMethodByName(moduleInstance, name) {
let requestMethod = Object.keys(metherPatternMapper).filter(key => {
const { pattern } = methodPatternMapper[key]
if (!(pattern instanceof RegExp)) {
// methodPatternMapper每一個屬性的value的pattern
// 既能夠是正則表達式字符串，也但是是正則類型的對象
pattern = new RegExp(pattern)
}
return pattern.test(name)
})
if (requestMethod.length !== 1) {
throw ` 解析${name}異常，解析獲得的方法有且只能有1個， 但實際解析到的方法個數是：${requestMethod.length} `
}
requestMethod = requestMethod[0]
return bindModuleMethod(requestMethod, moduleInstance,
methodPatternMapper[requestMethod].sendData)
}
/* * 將參數映射到路徑變量 * * @param url * @param params 被映射到路徑變量的參數 * * @return 將路徑變量替換好的URL */
function mapParamsToPathVariables(url, params) {
if (!url || typeof url !== 'string') {
throw new Error(`url ${url} 應該是URL字符串`)
}
return url.replace(/:(\w+)/ig, (_, key) => params[key])
}
export function bindUrls (urls = {}) {
// 爲何返回一個函數對象？後面會給你們解釋
return module => {
const keys = Object.keys(urls)
if (!keys.length) {
console.warn('urls對象爲空，沒法完成URL的映射')
return
}
const instance = module.prototype || module
keys.forEach(name => {
const url = urls[name]
if (!url) {
throw new Error(`${name}()的地址無效`)
}
// 根據urls對象動態定義模塊方法
Object.defineProperty(instance, name, {
configurable: true,
writable: true,
enumerable: true,
value: ((url, func, thisArg) => () => {
let args = Array.prototype.slice.call(arguments)
if (args.length > 0 && url.indexOf('/:') >= 0) {
if (isObject(args[0])) {
const params = args[0]
args = args.slice(1)
url = mapParamsToPathVariables(url, params)
}
}
return func && func.apply(thisArg, [ url ].concat(args))
})(url, resolveMethodByName(instance, name), instance)
})
})
}
}
複製代碼
爲了閱讀方便，我把關鍵的幾個地方都放到了一塊兒，但在實際項目當中，建議適當的拆分一下代碼，以便維護和測試。
咱們實現了一個將URL請求與模塊實例方法進行綁定的函數bindUrls()，並經過httpclient-module導出。bundUrls()的實現並不複雜。urls是一個以方法名做爲key，URL做爲value的對象。對urls對象進行遍歷，遍歷過程當中，先用對象的key進行正則匹配，從而獲得是相應的請求方法（見methodPatternMapper），並將請求綁定到一個函數中（見resolveMethodByName()和bindModuleMethod()）。而後經過Object.defineProperty()方法給模塊的實例（或者原型）對象添加方法，方法的名稱就是urls的key。被動態添加到模塊實例對象的方法在被調用時，先判斷與方法綁定的URL是否有路徑變量，若是有，則經過mapParamsToPathVariables()進行轉換，而後在執行以前經過resolveMethodByName()獲得的已經和請求綁定好的函數。
咱們用bindUrls()對以前的TagManager進行改造。
// TagManager.js
// ...
+ import { bindUrls } from 'httpclient-module'
class TagManager extends BaseModule {
constructor () {
/* ... */
+ bindUrls({
+ createTag: '/tags',
+ getTagPageableList: '/tags',
+ getTagFullList: '/tags/all',
+ getTag: '/tags/:id',
+ updateTag: '/tags/:id',
+ deleteTag: '/tags/:id'
+ })(this)
}
- createTag (data) { /* ... */ }
- getTagPageableList (page = 0, size = 20) { /* ... */ }
- getTagFullList () { /* ... */ }
- getTag (id) { /* ... */ }
- updateTag (id, update) { /* ... */ }
- deleteTag (id) { /* ... */ }
// ...
}
複製代碼
爲何bindUrls()要返回一個函數，經過返回的函數處理module這個參數，而不是將module做爲bindUrls的第二個參數進行處理呢？
這樣作的目的在於考慮兼容ES7裝飾器@decorator的寫法。在ES7的環境中，咱們還能夠用裝飾器來將URL綁定到模塊方法中。
import { bindUrls } from 'httpclient-module'
@bindUrls({
createTag: '/tags',
getTagPageableList: '/tags',
getTagFullList: '/tags/all',
getTag: '/tags/:id',
updateTag: '/tags/:id',
deleteTag: '/tags/:id'
})
class TagManager extends BaseModule {
/* ... */
}
複製代碼
這樣，咱們能夠經過bindUrls()，方便的給模塊添加一系列能夠執行URL請求的實例方法。
提高bindUrls()的靈活度
bindUrls()靈活度還有提高的空間。如今的版本對urls這個參數只能支持字符串類型的value，咱們以爲urls的value除了能夠是字符串外，還能夠是其餘類型，好比plain object。同時，key的前綴只能是create、update、get、delete四個，感受有些死板，咱們想能夠支持更多的前綴，或者說方法的名稱不必定要侷限於某種格式，能夠自由的給方法命名。
咱們對如今的版本進行一些小改動，提高bindUrls()的靈活度。
// ...
// 支持更多的前綴
const methodPatternMapper = {
- get: { pattern: '^(get)\\w+$' },
+ get: { pattern: '^(get|load|query|fetch)\\w+$' },
- post: { pattern: '^(create)\\w+$', sendData: true },
+ post: { pattern: '^(create|new|post)\\w+$', sendData: true },
- put: { pattern: '^(update)\\w+$', sendData: true },
+ put: { pattern: '^(update|edit|modify|put)\\w+$', sendData: true },
- delete: { pattern: '^(delete)\\w+$' }
+ delete: { pattern: '^(delete|remove)\\w+$' }
}
/* ... */
+ function resolveMethodByRequestMethod(moduleInstance, requestMethod) {
+ if (/^(post|put)$/.test(requestMethod)) {
+ return bindModuleMethod(requestMethod, moduleInstance, true)
+ } else if (/^(delete|get)$/.test(requestMethod)) {
+ return bindModuleMethod(requestMethod, moduleInstance)
+ } else {
+ throw new Error(`未知的請求方法: ${requestMethod}`)
+ }
+ }
export function mapUrls (urls = {}) {
return module => {
const keys = Object.keys(urls)
if (!keys.length) {
console.warn('urls對象爲空，沒法完成URL的映射')
return
}
const instance = module.prototype || module
keys.forEach(name => {
let url = urls[name]
+ let requestMethod = undefined
+ if (isObject(url)) {
+ requestMethod = url['method']
+ url = url['url']
+ }
if (!url) {
throw new Error(`${name}()的地址無效`)
}
+ let func = undefined
+ if (!requestMethod) {
+ func = resolveMethodByName(instance, name)
+ } else {
+ func = resolveMethodByRequestMethod(instance, requestMethod)
+ }
Object.defineProperty(instance, name, {
configurable: true,
writable: true,
enumerable: true,
value: ((url, func, thisArg) => () => {
let args = Array.prototype.slice.call(arguments)
if (args.length > 0 && url.indexOf('/:') >= 0) {
if (isObject(args[0])) {
const params = args[0]
args = args.slice(1)
url = mapParamsToUrlPattern(url, params)
}
}
return func && func.apply(thisArg, [ url ].concat(args))
- })(url, resolveMethodByName(instance, name), instance)
+ })(url, func, instance)
})
})
}
}
複製代碼
通過調整的bindUrls()對urls支持plain object類型的value。plain object類型的value能夠有兩個key，一個是url，就是接口的URL，另外一個是method，能夠指定請求方法。若是設置了method，那麼就不須要根據urls的key的前綴推導請求方法了，這樣可使得配置urls更加靈活。
const urls = {
loadUsers: '/users',
}
// or
const urls = {
users: { url: '/users', method: 'get' }
}
bindUrls(urls)(module)
module.users({ page: 1, size: 20 }) // => GET /users?page=1&size=20
複製代碼
如今，咱們只須要經過bindUrls()，簡單的定義一個對象，就能夠給一個模塊添加請求接口的方法了。
總結
回顧一些咱們對Axios這個http庫封裝的幾個階段
- 定義一個模塊，好比
UserManager，而後給模塊添加一些調用URL接口的方法，規定好參數，而後在界面層能夠經過模塊的方法來調用URL接口與後臺進行數據通訊，簡化了調用http庫API的流程。 - 假如項目中，接口愈來愈多，那麼會致使相應的模塊也愈來愈多，好比
VideoManager、EpisodeManager、CPManager等。隨着模塊模塊逐漸增多，咱們發現重複的代碼也在增多，須要提高代碼的複用性，那麼，能夠給這些Manager模塊定義一個基類BaseModule，而後將http庫相關的代碼轉移到BaseModule中，從而子類中調用URL接口的方法。 - 後來發現，即便有了
BaseModule消除了重複的代碼，但仍是存在重複的工做，好比手寫那些CRUD方法，因而，咱們將BaseModule獨立成一個單獨的項目httpclient-module，從以前的繼承關係轉爲組合關係，並設計了一個APIbindUrls()。經過這個API，咱們能夠以key -> value這種配置項的方式，動態的給一個模塊添加執行URL接口請求的方法，從而進一步的簡化咱們的代碼，提高咱們開發的效率。 - 最後，還給
bindUrls()作了靈活性的提高工做。
在整個http封裝過程當中，咱們進行了一些思考，好比複用性，通用性，靈活性。其最終的目的是爲了提高咱們開發過程的效率，減小重複工做。但回過頭來看，對於http庫的封裝其實並不是必定要作到最後這一步的樣子。咱們也是根據實際狀況一步一步迭代過來的，因此，具體須要封裝到哪一程度，並無確切的答案，得從實際的場景出發，綜合考慮後，選擇最合適的方式。
另外的，其實整個過程的思考（不是代碼），不只僅適用於Axios庫，也能夠用於其餘的http庫，好比SuperAgent或者fetch，也不只僅適用於http庫的封裝，對於其餘類型的模塊的封裝也一樣適用，不過須要舉一反三。
以上是咱們團隊封裝Axios的開發經歷，但願對你們有幫助和啓發。文中有不當的地方，歡迎批評和討論。
- 1. 記錄一次axios的封裝
- 2. axios二次封裝
- 3. Axios二次封裝
- 4. 記錄一次安裝WampServer的經歷
- 5. vue-axios二次封裝
- 6. Vue之封裝二次axios
- 7. axios二次封裝學習
- 8. axios統一封裝
- 9. axios的封裝
- 10. axios的封裝案例（一）
- 更多相關文章...
- • C# 封裝 - C#教程
- • RSS 歷史 - RSS 教程
- • C# 中 foreach 遍歷的用法
- • Docker容器實戰(一) - 封神Server端技術
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 記錄一次axios的封裝
- 2. axios二次封裝
- 3. Axios二次封裝
- 4. 記錄一次安裝WampServer的經歷
- 5. vue-axios二次封裝
- 6. Vue之封裝二次axios
- 7. axios二次封裝學習
- 8. axios統一封裝
- 9. axios的封裝
- 10. axios的封裝案例（一）