陽光溫暖的下午。我剛測試完最後一個頁面，git push 後,翻翻掘金,腦海裡憧憬著下班後和老婆出去happy的畫面.突然,測試屁顛屁顛跑來。
"粗大事了！頁面掛了。"
"怎麼可能？"。程式設計師語錄第一句，一個前端er也逃不過自身宿命的條件反射回答。
然後各種排查，繞了一圈，發現介面未按約定格式返回。因為之前後臺介面說的信誓旦旦，介面一定是按照約定的格式返回的，所以老司機我掉坑了。再也不相信山盟海誓了。
以上，開個玩笑。但是，在實際開發過程中，尤其是早期後臺介面還沒有開發完善穩定的時候，前端往往也是要並行開發的。這個時候，設計一套mock服務可以提供開發的進度保證。作為愛折騰的老司機，必須更進一步，想想如何做一個緊箍咒，套在後端介面上，讓後端介面老老實實返回約定的資料。
以前做後臺的時候，總是告誡自己，介面呼叫者傳遞的引數不可信。即使前端做了客戶端驗證，後臺自己也還是要做一遍引數校驗的，且後臺的驗證才是最關鍵的。現在老司機轉做前端了，反向思維一下，後臺可以無情的不相信前端的請求引數，前端也一樣可以無情的不相信後臺返回的資料。就是這樣無情。
擼起袖子，說幹就幹。
起手式
前端反向驗證後臺服務返回的資料格式最主要的環節就是如何判斷返回的資料格式？難道要我一個一個if語句去寫嗎？還好，只要會百度，沒有什麼困難擋不住。通過查閱資料，我瞭解到了Json-shceme規範，具體請參考：json-schema.org/。有了它，就等於是給我開啟了一扇大門，我只管往前蹚。
說一下大致過程。
設計思路
- 設計一個配置檔案，用於定義需要驗證的介面返回資料格式；
- 前端通過ajax請求介面資料；
- 介面返回資料後，先根據該介面名找到對應的json-schema配置檔案；
- 呼叫json-schema驗證庫驗證方法，如果驗證失敗，則返回異常提示。驗證通過，則資料繼續返回到前端上層。
- 各介面配置檔案在單頁載入前提前載入。
- 可以設定總開關，配置是否開啟資料驗證；
- 可以針對單個介面設定開關。總開關優先；
術語
介面
指後臺應用服務提供的webservice介面。
Json-scheme
json格式驗證的規範。具體請參考：json-schema.org/
配置檔案格式說明
貼一個我的配置檔案截圖
description
描述資訊。
disable
是否禁用，如果無該屬性，預設啟用。
jsonSchemes
各介面的json-chema配置。由於一個介面的配置過長，可以單獨寫在獨立json檔案，部署時，通過工具自動合併。
Json-Schema規則說明
{
"disable": false,
"schema": {
"type": "object",
"required": [
"code",
"data"
],
"properties": {
"data": {
"type": "object",
"properties": {
"totalCount": {
"type": "integer",
"minimum": 0
},
"data": {
"type": "array",
"uniqueItems": true,
"items": {
"type": "object",
"properties": {
"occurTime": {
"type": "string"
},
"lat": {
"type": "number"
},
"lon": {
"type": "number"
}
},
"required": [
"occurTime",
"lat",
"lon"
]
}
}
},
"required": [
"totalCount",
"data"
]
}
}
}
}複製程式碼以上規則大致說一下：
- 介面返回的資料頂層是一個json object。必須有兩個欄位：
code和data。 - 然後逐層往下，data欄位是一個
object，必須要有totalCount和data欄位。 totalcount是一個整數，且最小值是0；data是一個陣列，不能重複。data裡的每一項是一個object，必須要有occurTime、lat、lon欄位；
大概就是這樣子。
disable
是否禁用。如果沒有該屬性，則預設不啟用。
scheme
Json-schema配置。
具體規則可參考：json-schema.org/latest/json…
實現
實現的核心就是採用了json-scheme validation的javascript實現tv4。
- 官方demo：geraintluff.github.io/tv4/。
github地址：github.com/geraintluff…
配置步驟
根據要驗證的介面，新建json配置檔案，以介面名作為json檔名；
- 按照設計規則編寫json配置檔案；
- 基於nodejs執行mergeApiJsonConfig.js，合併配置，完成配置，執行即可。mergeApiJsonConfig.j是我寫的一個簡單的合併配置檔案的指令碼，就不獻醜貼程式碼了。
缺點
由於前端每呼叫一次介面，返回的時候都會進行一次驗證，可能會有一些效能的損耗。由於我之前的專案量級沒那麼大，所以效能也不是很明顯有下滑。
最後
在查mock服務的時候，貌似阿里的前端們搞了一個mockjs，用於生成一些隨機模擬資料。通過配置各種隨機規則，這個有點類似json-scheme。不過他的配置語法稍微不太一樣，主要針對測試批量生成資料的場景。有興趣的同學可以過去看看：mockjs.com/。
反向驗證機制上線後，老司機可以安心的回家陪老婆了。
全文完。
本文對你有幫助？歡迎掃碼加入前端學習小組微信群：
