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