API調試的幾個問題的解決方案

  進了新的團隊，開始了新的項目，前端用的vue全家桶。前兩天開始接口調試，過程當中遇到了幾個問題，這裏作一下Mark和分享。

使用Postman測試接口

  接口對接過程當中，若是出現問題，最好使用接口測試工具確認一下問題在前端仍是後端，而後才能更近一步處理。我這裏一直是使用Postman,若是你們有其它好的接口測試工具，歡迎提出來，你們能夠用用試試。
  Postman——完整的接口開發環境。用來測試後端接口是否正常，最合適不過了。固然它還有很其它高大上的用法，我暫時沒有體驗過。具體使用：使用 PostMan 進行自動化測試
  接口測試的目的就是確認後端接口是否正常，若是使用Postman測試接口能夠正常返回數據，但又沒法調通，那確定就是咱們前端的問題沒跑了，就不必去找後端挨懟了；若是不能正常返回數據，那就義正詞嚴的去找後端(固然，有話好好說)。

proxyTable配置代理

  先後端分離，意味着就會先後端的項目就不會在同一個目錄或服務下，也就意味着跨域。
  vue-cli使用webpack模板生成的項目，會自動添加webpack-dev-server依賴包，經過它的proxy選項能夠配置代理，幫咱們解決跨域的問題。在項目文件的根據目錄下的config文件的index.js的dev配置項中，有個proxyTable能夠進行代理配置。
  由於proxy只是對接口作代理，而不是作替換，因此在瀏覽器中咱們看到的仍是代理前的接口地址，並不是代理後的地址。所以如何知道代理有不用配置正確，還真是個問題。下面上示例：

proxyTable: {
    '/apis': { // 將https://www.exaple.com映射爲/apis
        target: 'https://www.exaple.com', //映射地址
        changeOrigin: true, // 是否跨域,true表示是
        pathRewrite: {
            '^/apis': '' // 將/apis替換爲空,
        }
    }
}
//上面的配置，將'/apis'開頭的請求進行代理，代理至https://www.exaple.com
//而且/apis僅僅只是用來作匹配的，須要重寫。
//就是說，若是你在頁面裏請求接口：/apis/getUserInfo
//將被代理成：https://www.exaple.com/getUserInfo

  具體項目中該如何使用,再看幾個示例：

//若是大家項目的接口存在某個公共路徑
//好比大家的接口是這樣的：192.168.1.110/api/a,192.168.1.110/api/b,192.168.1.110/api/c,
//就可使用api來映射，如
proxyTable: {
    '/api': { 
        target: '192.168.1.110', //映射地址
        changeOrigin: true
    }
}
//而後就能夠直接請求：/api/a，/api/b，/api/c


//若是大家項目的接口不存在公共路徑
//好比大家的接口是這樣的：192.168.1.110/a,192.168.1.110/b,192.168.1.110/c,
//就能夠添加一個/apis來映射，如
proxyTable: {
    '/apis': { 
        target: '192.168.1.110', 
        changeOrigin: true,
        pathRewrite: {
            '^/apis': '' // 將/apis替換爲空,
        }       
    }
}
//請求接口爲：/apis/a，/apis/b，/apis/c
//由於'/apis'只是用來作映射的，真實接口並無這個路徑，因此須要使用pathRewrite將'/apis'替換成空
//'^'表示只替換開頭的'/apis'

//若是大家項目的接口存在多個公共路徑
//好比大家的接口是這樣的：192.168.1.110/apis1/a,192.168.1.110/apis1/b,192.168.1.110/apis2/a,192.168.1.110/apis2/b
//能夠添加多個映射，如
proxyTable: {
    '/apis1': { 
        target: '192.168.1.110', //映射地址
        changeOrigin: true
    }
    '/apis2': { 
        target: '192.168.1.110', //映射地址
        changeOrigin: true
    }
}
//使用：/apis1/a,/apis1/b,/apis2/a,/apis2/b

確認後端接受的數據傳遞方式

  測試第一個接口時，以JSON串格式傳遞參數，明明參數都傳了，後端依然提示缺乏參數。經過測試，發現是後端不支持JSON串方式傳送參數。處理方法：手動將數據轉換成'x-www-form-urlencode'格式或'form-data'格式；或者引入qs依賴，來轉換參數傳送方式。

接口整合

  生產和開發環境的接口，頗有可能會不一樣。這時，我會就須要經過整合接口，來實在生產和開發調用不一樣的基礎接口，同時也能夠對錯誤和一些基礎參數進行統一配置。以下：

// index.js
// 導入axios和qs模塊
import axios from 'axios' 
import qs from 'qs'

// 根據環境，配置不一樣的baseURL
const baseURL = process.env.NODE_ENV === 'production'
  ? 'https://www.exaple.com'// 生產
  : 'http://192.1.2.110:8180' // 開發

//建立axios實例，設置基礎url和超時時間
let axiosIns = axios.create({
  baseURL,
  timeout: 3000
})
//攔截請求發送
axiosIns.interceptors.request.use(config => {
  return config
}, error => {
  return Promise.reject(error)
})
//攔截請求響應
axiosIns.interceptors.response.use(function (rawResp) {
  return rawResp
}, function (error) {
  return Promise.reject(error)
})
//導出一個返回aixos請求的函數
export default function axiosCreation ({method = 'GET'} = {}, enableQs = true) {
  let arg = arguments[0]
  let opts = Object.assign({method}, arg)
  enableQs && opts.data && (opts.data = qs.stringify(opts.data))
  return axiosIns(opts) 
}

  根據業務，咱們能夠分類建立不一樣的api請求文件。

//traffic.js
//導入index.js的axiosCreation函數
import axiosCreation from './index.js'

/**
 * 導出一個接口topCross
 */
export function topCross (params) {
  return axiosCreation({
    url: '/traffic/topCross',
    data: params
  })
}
...
export function topCongestion (params) {
    ...
}
export function OnroadNum (params) {
    ...
}

  在頁面中使用API,咱們只須要導入須要用到的接口，如

import {topCongestion} from '../../api/traffic.js'
...
...
topCongestion({a:1,b:2})
  .then(data => {console.log(data)}) //請求成功
  .catch(err => {console.log(err)})  //請求失敗