痛点
项目中前端和后端通常是并行开发，为了减少等待后端接口开发的时间，我们经常需要在本地模拟后端接口用来测试前端效果。这种做法称之为构建前端Mock。平日里我接触的前端Mock方法大致可以分为以下两种：
- 本地启动一个静态服务，将所需要的接口写成json文件，根据接口名字将文件放在项目目录下。
- 再启动一个Server作为Mock Server，使用第三方Proxy将Mock Server的接口代理到静态服务器上。
第一种方法是接触的最多的方法，这做相对来说相对简单，可是带来的弊端也很多。如果项目的接口较少维护起来还比较容易，但是一旦涉及到数十个接口的调用，我们就需要在项目里写新建许多个json文件，如果恰好后端接口的路径又比较长的话，那项目目录将会十分的混乱。比如“ddos/data/details/todayCleanTime.json”，对应的moch目录必须是
--ddos
|--data
| --details
|--todayCleanTime.json
除此之外，通常情况下接口并不一定就会以json结尾（后端同学也许并不会听你解释。。）
如果按照RESTFUL的格式书写，比如"api/zoos/animals"，那么我们需要准备书写两套调用接口代码，一种以json格式结尾作为本地mock，另一套才是线上接口代码,每次build构建代码时，一定得记得将调用接口的地方改为线上代码。这种做法效率太低了。。
第二种方法则避免了修改接口的麻烦，在本地的Mock Server中模拟一个和线上一样的接口，这样的Mock也更接近于线上的环境。我们当然不用从头用Node或者Php写一个完整的后端服务，已经有许多工具造好了轮子。
我试用了许多工具，最后觉得还是** Json-Server **最为方便。这个工具在github上有11000个star，可见他的火爆之处。有便于其他同类工具，Json-Server基于REST API，配合使用Proxy，效率极其高。下面我简单说下使用方法，以及我在项目中是如何与Webpack整合的。
30秒内创建完整的REST API
安装Json-Server：
npm install -g json-server
在项目中新建一个test.json文件，我们现在要模拟一个/issues和/total接口
\\ test.json
{
"issues": [
{
"id": 101,
"text": "something is not right"
},
{
"id": 102,
"text": "crash on login"
}
],
"total": {
"data": {
"exchange_count": "10",
"share_count": "23",
"patent_count": "7",
"article_count": "37",
"exchangeRecords": []
},
"success": true
}
}
启动服务
json-server --watch test.json --port 9090
访问localhost:9090
现在可以直接按照RESTFUL的规范调用这个接口，并且所做的POST和DELETE等请求，会直接修改test.json文件的值。
➜ ~ curl http://localhost:9090/issues
[
{
"id": 101,
"text": "something is not right"
},
{
"id": 102,
"text": "crash on login"
}
]%
➜ ~ curl http://localhost:9090/issues/2
{}%
➜ ~ curl http://localhost:9090/issues/101
{
"id": 101,
"text": "something is not right"
}%
➜ ~ curl -X DELETE http://localhost:9090/issues/102
{}%
除此之外，还可以继续增加路由规则。创建一个routes.json文件
{
"/api/": "/",
"/blog/:resource/:id/show": "/:resource/:id"
}
启动服务
json-server --watch test.json --routes routes.json
如果接口并不是Restful或者比较冗长，你也可以采取路由的方法模拟。
整合Webpack Dev Server
在项目中使用JsonServer，还需要再做点小处理。通常在本地调试的时候我们已经启动了一个静态服务，因此需要用代理服务进行跨域（两个服务分别在两个端口上）。对于使用Webpack打包的项目，已经使用了它自带的webpack-dev-server服务，它很贴心的提供了proxy参数来解决这个问题。在webpack.config.js做以下配置:
devServer:{
proxy: {
'/gm/api/*': {
target: 'http://localhost:9090',
secure: false
}
}
}
在package.json中新添加一个scripts:
"scripts": {
"dev": "webpack-dev-server --inline --hot --no-info",
"build": "cross-env NODE_ENV=production webpack --progress --hide-modules",
"mock": "node_modules/.bin/json-server --watch mock/db.json --port 9090",
"mockdev": "npm run mock & npm run dev"
},
由于json-server是命令行工具，若没有全局安装需要用相对路径去调用它: node_modules/.bin/json-server 。路径不能少，否则会提示找不到命令哦。
这个世界终于清净啦！在代码中每次调用/gm/api/issues的时候，都会调用到json-server服务去，可以真是模拟线上的接口调用情况。现在可以把所有接口都集中写在一个json文件中，代码里面线上环境和本地Mock也保持了一致，不需要再切来切去啦！
如果你使用的本地静态服务并没有提供代理的功能，那可以使用 阿里的开源工具anyproxy ，同样给力！
加上Faker试试？
如果我们想在Mock的时候生成更多的随机数据，这个时候就需要faker了！faker.js可以用来产生大量的模拟假数据，配合json-server，我来给大家举个栗子：
npm install faker lodash –save-dev
在项目中新建一个generate.js文件
module.exports = function(){
var faker =require("faker");
vae _ = require("lodash");
return {
people: _.times(100,function (n) {
return {
id: n,
name: faker.name.findName(),
avatar: faker.internet.avatar()
}
})
}
}
使用命令
json-server generate.js
Done！生成了100条数据，关于faker的更多用法请参照官网，它能够生存许多常见的随机数据，faker.js。
Tips
在使用的过程中，我发现WebStorm有一个很好用的小工具，叫做TestRestfulWebService。（双击shift输入工具名快速唤出）可以直接用来测试json-server。