開發現狀
首先，先看下在 前後端分離 模式下，前端開發同學一直面臨著這些問題：
文件編寫難以開展，更難以維護缺少介面文件，前端開發時間點滯後，影響專案進度沒有一個即時呼叫的後端服務，需要不斷在頁面中寫假資料，增加開發量即使有了介面文件，往往也因為不清晰的描述，無法準確使用欄位，增加溝通成本什麼是 YApi
旨在為開發、產品、測試人員提供更優雅的介面管理服務。可以幫助開發者輕鬆建立、釋出、維護 API。
它的 視覺化的介面管理介面，整合 Mock 服務，足夠輕鬆解決上述這些問題。
Github 上 20k 的 Star 數足以證明它在介面管理領域大家對它的認可。
同時，它還有如下出眾的特性：
支援 許可權管理，私有化部署：方便，安全地在公司內部進行搭建，和人員管理支援 資料匯入：對於匯入 Swagger、Postman 資料，方便遷移歷史專案文件支援 自動化測試：為測試團隊進行賦能環境安裝
因為 YApi 主技術棧為前端，只要準備好 nodejs 和 mongodb 環境即可透過 yapi-cli 方便的完成，這裡不做贅述。
更多詳見：Yapi 安裝（https://hellosean1025.github.io/yapi/devops/index.html#%e5%ae%89%e8%a3%85）
基本使用
成功安裝後，下面展示如何簡單的維護一個介面 api：
首先在指定空間下新建一個新專案為新專案設定統一的介面字首等基礎資訊對不同模組的介面設定不同的資料夾進行分類建立第一個介面定義介面的 Http 方法 和 請求 URL（還有所屬分類，以及介面名稱）編寫引數按照 Http 協議（主要是 Content-Type ），定義後端需要的請求引數和響應引數執行這裡的執行是基於 YApi 的 Mock 服務，依靠此服務，能讓完全前端獨立出來，不再依賴後端服務預覽作為文件供所有開發人員閱覽資料 MockMock.js
參考“基本使用”，只是完成了介面文件的閱讀，及基礎呼叫。下面來介紹 YApi 的核心功能：資料 Mock。
資料 Mock 的功能基於 Mock.js 實現，是由 墨智大佬 打造的。
下面配合一些使用場景來看下 Mock.js 與 YApi 的進階使用方法：
Mock 佔位符
Mock.js 內建很多 Random 功能，便於我們能快速定義一些有意義的假資料。
比如：
@boolean: 返回一個隨機的布林值@natural: 返回一個隨機的自然數（大於等於 0 的整數）。@integer: 返回一個隨機的整數。@string: 返回一個隨機字串。@word: 隨機生成一個單詞。@province: 隨機生成一個（中國）省（或直轄市、自治區、特別行政區）。@email: 隨機生成一個郵件地址。@id: 隨機生成一個 18 位身份證。…以上這些都可以在 https://github.com/nuysoft/Mock/wiki/Mock.Random 快速查閱到。
比如有一個 “使用者列表” 介面，含有使用者名稱，年齡，使用者 id 等欄位。當我們沒有 mock 時，將返回如下資料：
上述資料在實際使用中毫無意義。我們更期望得到如下資料：
下面示意，如何使用 mock 佔位符對欄位進行修飾：
執行後，將得到 “看得懂” 的資料，這樣維護的文件對前端和測試人員的體驗感將提升很多：
高階 Mock期望
比如在 使用者登入場景，我們希望輸入 A 賬戶 可以正常登入，其他賬戶則登入失敗。
但在開發階段，後端介面邏輯都沒實現，甚至資料庫連表都不存在，那前端怎麼做？
這時就可以使用 YApi 的 高階 Mock 期望 特性：
透過定義 引數過濾 來指定可以正常登入的賬戶資訊：
在執行介面，當 username/password 為 eminoda/123456 時才返回預期的成功報文：
指令碼
單靠 Mock 內建的佔位符，和簡單的期望規則無法模擬出實際預期的效果。
比如，希望在 “使用者列表” 介面中 company 欄位從某個陣列集合中挑選某個作為返回結果值。
這時就需要開發掌握一些 Mock.js 技巧以及 javascript 的語法來完成模擬邏輯（但這些對於經歷過 jsp 的後端來說都不是問題，這和前端如今 vue，react 扯不上關係）：
執行後，將得到如下資料：
高階 Mock 指令碼中定義了一些全域性變數，我們可以從 header、params、cookie 中拿到請求頭，和請求引數資訊；以及可以透過 mockJson、resHeader、httpCode… 自定義響應資料。
自動化測試這塊內容將更多涉及測試（開發）人員，一個專案迭代多次，沒有人會知道哪些介面對哪些功能造成什麼後果，一個 高覆蓋率的測試用例+可自動化的指令碼 將為專案迭代提供保障。
多數公司的測試都偏向於“人肉”，必然會有不確定性，不穩定性。YApi 為我們提供了一套“可操作”的自動化測試方案：期望/指令碼+自動化執行（報告）
新增用例示意簡單的用例建立
在測試集合中關聯對應介面針對“登入介面”，定義一個能登入成功的請求資料編寫 Test，驗證預期結果不用擔心怎麼寫，在右側都有快捷方式（點一下，即可在左側程式碼區生成程式碼）這樣就完成了一個用例的編寫。參照上述步驟，再定義一個“登入失敗”的用例（用於對比）請求引數填寫“錯誤”的值，在 Test 驗證錯誤的預期判斷用例 comb比如我們有個“刪除使用者介面”，遵循 Restful 規範，透過 path 作為 id 引數來刪除目標使用者。
YAapi 也提供了 變數引數 對應這樣的場景：
透過特定表示式，來獲取上個介面的引數：
而這個 4822 就是測試集合中的 key 值（使用者列表）：
自動化測試用例當完成一批的測試集合用例後，可以批次進行自動化測試，從而看介面服務的目前情況。
如果我們資料 Mock 足夠真實，用例 Test 定義的足夠完善，基本可以應對每次系統的迭代釋出。一旦用例不透過，只會有兩種情況：介面邏輯發生變化、用例寫錯。
另外，YApi 提供了服務端測試，我們可以獲取到用例測試的報告（全量的介面資訊，整體響應的時間等維度結果）
最後本文只起拋磚引玉作用，示例了小部分的 Mock.js 使用以及 YApi 的實際使用場景，更多的需要開發和相關人員到 YApi 及相關站點閱讀更多資料。
另外，可惜的是 YApi 可能不再進行維護，需要額外更多功能的團隊就需要二次開發，或者尋找其他適合的工具。
當然也感謝這些大佬對社群的貢獻。
#YApi# #Mockjs#