一條命令解決接口Mock

背景

在前端或客戶端開發中，常常須要依賴後端同窗開發的API。爲了可以先後端並行開發，前端一般會採用Mock數據的方法，經過模擬api假數據進行頁面渲染。等到後端API開發完畢再接入真實API進行調試。

API數據Mock的方法有不少，經常使用的有如下幾種：

前端打包工具安裝Mock插件

好比Grunt, Gulp, Webpack等等都有相應的mock插件，開發者須要根據不一樣的項目類型來作配置。其原理是啓動一個本地服務器實現接口請求。因爲是模擬網絡請求，因此有時還須要根據需求對一些打包腳本進行修改。該方法的缺點是針對不一樣的工具須要有不一樣的方案，有必定的安裝和適配成本，而且只針對使用打包工具的項目。

外部Mock服務平臺

業界有一些Mock的解決方案，提供一個第三方平臺，開發者在平臺上配置api接口，而後直接調用平臺接口進行調試。比較出名的如 easy-mock。

這種方法的優勢是無任何插件依賴，全部項目均可以直接訪問使用，無需安裝，因此對客戶端也是通用的。可是帶來另一個問題是數據的泄露，一些隱私度比較高的項目可能會以爲把模擬數據放到其餘平臺上也是不安全的。固然easy-mock也考慮到這個問題，開源並支持用戶直接部署項目到公司內網。但這個須要主機，數據庫等資源的支持，落實難度較大。

寫死數據

第三種是比較直接的，就是在前端寫死數據，接口不發出請求而是直接返回。這種方法對於一些小的活動項目也許是不錯的選擇。可是構造的數據模式有限，也沒法模擬真實的網絡環境

在之前的開發中使用的基本是這三類方法，可是這些方法都有上述提到的明顯的侷限性。

另外一種方式

爲了不以上方案中的缺點，本文介紹另一種mock的思路

對於Mock數據，咱們但願它在項目中的存在只是一個文件夾，裏面定義了每一個接口的返回數據。開發者不須要配置項目插件，每一個項目均可以簡單的經過一個命令啓動mock服務，並監聽這個目錄。這個Mock服務須要具有如下功能：

1. 模擬接口請求，靈活配置返回數據
2. 在開發人員間共享模擬數據，而不是隻存在本地，也不是放在外網
3. 不要繁瑣的安裝配置，最好一個命令開啓即用
4. 對於全部類型的前端項目都是通用的
5. 提供一些複雜需求的拓展功能

基於以上思路開發了一個工具 l-mock

實現數據mock只需三步：
1.全局安裝

npm i l-mock -g

2.初始化mock目錄, init命令在project根目錄下生成mock目錄，並放置demo接口

cd path/to/project
lmock init

3.運行, 進入生成的mock目錄，運行start命令，直接訪問localhost:3000/a 則可看到/a接口返回

cd mock
lmock start

第一次初始化後，後面的開發只須要在mock目錄中運行lmock start就能夠開啓接口模擬。

對於有package.json的前端項目，能夠直接配置在npm命令中，日後就運行 npm run mock

"scripts": {
  "mock": "cd mock && lmock start",
}

怎麼來編寫一個模擬接口呢？舉一個例子:

path/to/project/mock/a.js 模擬了一個get請求

module.exports = {
  url: '/a',
  method: 'get',
  result: {
    'status|1': ["no_login", "OK", "error", "not_registered", "account_reviewing"],
    'msg': '@csentence()',
    'data': {
      a: 2
    }
  }
}

以上js返回的json內容以下

params	description
url	配置API地址, 支持正則匹配模式
method	配置請求方法，支持RESTFUL
result	定義返回內容

result 能夠直接返回json內容，經過Mockjs,能夠生成動態的數據內容，好比上面的@csnetence()會隨機生成一個段落的文字

Mockjs的語法不少，能夠參考其文檔。

該工具還有一些拓展功能，須要用到複雜接口邏輯的，能夠在result返回方法中配置。

詳細的使用方法能夠參考工具文檔 l-mock

若是你的項目中正好須要用到數據Mock，不妨試一試。