mock server相關解決方案

先後端分離以後

先後端分離後, 你們今後進入了所謂的並行開發時代. 一旦完成先後端的(邊界)分工, 你們就能夠各司其職了.

前端在與後端交互時, 要想有效地提升工做效率, 後端的接口文檔就是重中之重了.

接口文檔還不夠

所謂的接口文檔, 即一份數據的契約書. 前端的全部邏輯和展示所有依賴接口文檔中規定的數據結構.

可是光有接口文檔不足以提高前端的開發效率, 由於前端開發時, 必須調用實實在在的接口和數據才能看到結果, 儘早跑通全部的前端流程, 這纔是效率的根本.

在先後端並行開發的時代, 前端開發時, 後端也纔開發, 接口尚未開發完, 後端拿什麼給前端調用.

那麼問題來了, 咱們怎麼作一份可以調用的接口文檔呢?

假數據時代

前端不能夠傻傻地等後端接口開發完, 纔開始作前端的邏輯, 所以咱們習慣了作假的接口數據, 讓前端工做能夠順利地進行下去, 加快開發進度.

那麼咱們都嘗試過哪些手段來作假數據呢?

• 原始的靜態數據文件

  例如將 mock-data.json 放在項目的根目錄, 直接經過 ajax 調用便可.

• 使用 puer 或相似工具提供的 mock 功能

  須要一個 route.js, 在裏面實現接口來提供假數據

  mock請求

  假設你的靜態頁面開發到必定程度，須要與服務器端交互了，然後臺服務還徹底沒法聯調，這實際上是屬於最簡單的先後端分離開發的場景。通常而言， 做者會經過如下幾種方案。

  • 層級1: 經過代碼解耦，直接在前端mock數據

    這種方式影響較大，並且不管你解耦的如何，都會增長最終上真實環境的切換成本。

  • 層級2: 經過fiddler等調試代理工具mock數據

    優勢是到正式環境的切換成本小，但配置成本較大，也接口mock也有侷限性並基本上只能是靜態數據模擬。

  • 層級3：利用puer無痛的解決這個問題

    puer提供了叫插件(addon)的功能，集成了express的route.js來達到最簡的路由配置，能夠提供基於真實http請求與相應的動態的mock數據。

這些方法的弊端很明顯了, 用過的都知道, 太缺少靈活性了, 假數據還不夠假, 不方便作隨機的輸出.

• 靜態數據文件就不用說了, 文件裏面就幾條死的數據, 確定作不到隨機變化. 假如前端須要看 100 條數據的結果呢? 你是複製粘帖 100 次嗎?
• 依靠 puer 能夠加入隨機因素, 但隨機機制還得本身去實現, 不夠方便

那麼咱們使用前端的 Mock 庫來實現隨機的數據機制, 不就 OK 了嗎?

因而我嘗試了 Mock.js, 在前端解決前端的假數據問題.

<script src="http://cdn.bootcss.com/zepto/1.2.0/zepto.min.js"></script> <script src="http://rawgit.com/nuysoft/Mock/refactoring/dist/mock-min.js"></script> <script> // 攔截 ajax 請求輸出假數據, 至關於定義了一個假的接口 Mock.mock('/api/users', {  'users|1-10': [{  'id|+1': 1  }] });  $.ajax({  url: '/api/users',  success: function(result) {  console.log(result);  } }); </script>

由於 Mock.js 能夠攔截前端的 ajax 請求, 所以我只要在開發時按照接口文檔給出的接口和數據, 讓 Mock.js 去攔截接口並提供隨機的假數據便可, 例如實現一個開發時用的 mock-api.js.

<script src="http://cdn.bootcss.com/zepto/1.2.0/zepto.min.js"></script> <script src="http://rawgit.com/nuysoft/Mock/refactoring/dist/mock-min.js"></script> <script src="mock-api.js"></script> <script> // 前端的業務邏輯正常開展, 徹底無感知 $.ajax({  url: '/api/users',  success: function(result) {  console.log(result);  } }); </script>

當後端接口開發完成後, 去掉 mock-api.js, 便可切換到後端接口, 前端代碼不須要作任何修改.

mock server 纔是將來

在前端使用 Mock.js 是能夠造出一個"假的接口", 還能夠配置出隨機數據, 但畢竟不是真正的後端接口, 還須要在前端引用一段定義假接口的代碼(例如 mock-api.js), 勢必會形成管理上的問題. 想想若是有 20, 30 個頁面都要引用了 mock-api.js, 後端接口完成後, 你千萬得記得將 mock-api.js 從這些頁面中去掉, 是否是以爲有點累贅, 不夠智能啊.

看來是時候本身寫一個 mock server 來提供假接口假數據了, 爲前端提供像模像樣的假後端接口.

基於上面的那些實踐, 忽然就有了靈感, puer + mockjs 怎麼樣? puer 來提供 mock 機制, Mock.js 來提供隨機數據, 因而 puer-mock 就誕生了.

puer-mock

puer-mock = Puer + Mock.js = 一個簡單易用 mock server, 爲你提供可配置的接口和隨機數據.

使用了 puer-mock 後, 你只需像這樣來配置接口

{
    "api": { "GET /api/users": { "response": {} } } }

而後調用這個接口查看結果

puer-mock 還提供了內置的 API doc, 能夠看到你定義的全部 API

puer-mock 具備如下特色

• 簡單配置便可定義 mock 接口, 不須要你寫代碼
• 配置接口及時生效, 修改即用
• 支持 JSONP 的方式調用接口
• 支持 CORS 的方式跨域調用
• 幫你輸出一份接口文檔, 方便在開發過程當中溝通交流

固然 puer-mock 還不僅有這些功能, 讓你一秒鐘就能擁有一個強大的 mock server, 因此請不要再本身手工作假數據了, 趕快嘗試一下讓你的工做效率翻番吧!

接口管理平臺

有了 mock server, 能夠幫助咱們解決掉一些先後端接口協商的問題, 但 mock server 並無解決掉全部先後端接口的問題, 例如:

• 後端接口修改了怎麼辦?

  他修改他的, 沒有通知你怎麼辦? 你的 mock server 仍是老的數據結構, 這就是 mock server 與真實接口的同步問題.

  所以最好的辦法仍是由後端提供一個 mock server 給前端使用, 即便他們的接口尚未開發完成. 這樣當實現後端接口的代碼發生改變時, 保持 mock server 也同步更新.

• mock server 應該是真正的後端接口 server 的一個開關功能

  mock server 實際上是供開發時使用的, 宗旨在於提高前端的開發效率, 並下降溝通成本, 當後端接口尚未開發完時, 前端就能夠先作本身的事了.

  那麼咱們更進一步來說, mock server 能夠看做是真實的接口服務器提供的一個附加功能而已. 當某個後端接口尚未開發完時, 他提供 mock server 服務, 當接口開發完, 他就提供真正的後端接口了, 這樣對前端來講徹底是無感知的.

所以理想的 mock server 最好由後端來提供, 由於接口是由後端來實現的, 並且 mock server 的配置最好是根據後端代碼來生成(例如經過註解的方式), 這樣一來後端代碼的修改就能方便地同步更新 mock server, 這就是咱們理想中的接口管理平臺.

那麼咱們總結一下接口管理平臺應該是怎麼樣的? 若是有這麼一個統一的接口管理平臺, 團隊協做是否是會更加的高效.

• 由後端接口服務器提供 mock server 功能
• mock server 的配置由後端代碼生成
• 後端接口未開發完成時提供 mock 數據
• 校驗接口的輸入, 即輸入參數是否符合接口的定義, 以前咱們都只是作了 response 的約定, reqeust 約定也很重要
• 控制 mock server 的開關, 能夠控制一個接口是處於 mock 模式, 仍是真實模式
• 還能夠延伸出更多的可能性, 例如作接口自動化測試

如下是目前的一些實現方案, 能夠做爲接口管理平臺的技術選型.

• RAP

  RAP經過GUI工具幫助WEB工程師更高效的管理接口文檔，同時經過分析接口結構自動生成Mock數據、校驗真實接口的正確性，使接口文檔成爲開發流程中的強依賴。有告終構化的API數據，RAP能夠作的更多，而咱們能夠避免更多重複勞動。

• AMP

  Api manage platform

• Creating Help Pages for ASP.NET Web API

  When you create a web API, it is often useful to create a help page, so that other developers will know how to call your API. You could create all of the documentation manually, but it is better to autogenerate as much as possible. ASP.NET Web API provides a library for auto-generating help pages at run time. Swashbucklethat uses ApiExplorer to generate Swagger Docs.