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)})  //请求失败