前言
隨著網際網路的發展，API變的至關重要。根據統計，目前市面上有上千萬的開發者，網際網路專案超過10億，保守統計涉及的 API 數量大約有 100 億。這麼大基數的API，只要解決某些共有的痛點，將會是非常有意義的事情。我們總結了API管理方面的問題，發現與API相關的文件，除錯，測試和資料Mock 在工作中效率是非常低下的。
業務痛點
介面的維護管理非常耗時，大概佔用了30%開發時間。後端程式設計師要維護對於他們冗餘的文件，前端程式設計師又因為後端開發提供的文件不準確，導致浪費了大量的時間。
介面的正確性和穩定性很難保證，前端工程師為了處理各種資料異常情況，將會寫大量異常處理邏輯。傳統的介面自動化測試成本非常高，開發一個介面可能只需要一天，但寫介面測試用例，需要花費好幾天的時間。
對於前端程式設計師，在後端功能沒有開發完成之前，他們需要介面返回資料 Mock ，以便不影響開發進度。傳統的資料 mock 是把模擬資料寫到專案程式碼裡，這麼做會帶來更多新的問題，首先後端程式設計師定義的介面隨著需求、架構涉及隨時發生變化的，如果前端程式設計師完全按照最初的設計定義mock資料，將會和實際做出來的介面有很大的出入。
沒有一個標準化的流程統一處理，這個過程是非常分散的，需要配合非常多的工具，效率比較低。
市場產品調研
我們期望有一個完整的介面工具，協助開發人員在簡單易用的GUI介面除錯，管理文件和測試介面。於是開始尋找市面上類似產品，經過一段時間的分析，最終我們找到了幾個比較有代表性的產品 Rap，Nei，Easy-Mock。同時我們按照自己的訴求列出了一些關鍵的特徵：
Nei 是網易前端事業部的產品，在這些產品中算是做得比較好的， nei 專注做 saas 服務這塊，沒有開源版本。對於去哪兒內部，肯定不會把公司機密的介面資料放到第三方平臺。
Rap 是阿里媽媽 MUX 團隊2013年出的一款產品，從時間上看是同類產品中最早的。Rap 是後端工程師基於 java 開發的，如果想定製部分功能，還需要學習 java，而我們部門大家對 java 都不熟悉。另一方面 Rap 沒有介面測試功能，而後端使用其他工具（postman， restlet）測試介面，前後端開發人員沒有使用的統一工具。
Easy-Mock 是大搜車無線團隊出的一款產品，Easy-Mock 定位是介面資料的模擬，解決前端依賴後端介面資料的問題，在同類產品中 mock 服務做得比較好。Easy-Mock 專注於前端資料的模擬，但無法解決去哪兒現有的問題。
Rap 和 Easy-Mock 只是針對開發人員的單一工具，他們只關注了開發流程某一方面，並沒有站在全域性的角度去解決問題，我們的目標是整合介面開發過程中的工具。所以我們開始自主研發一個全新的介面管理平臺，我們希望它能夠提供介面文件管理，介面資料模擬（Mock），介面除錯，自動化測試等功能，讓前後端介面相關的工作進行的更加高效。這就是 YApi 介面管理平臺斐然由來。下面聊聊 YApi 是如何解決上述的痛點。
解決方案
- 共同維護一份介面定義，打通各個環節
在後端開發介面過程中，開發和測試是必不可少的環節。如下圖所示，按以往的做法，介面文件管理因為沒有跟開發和測試整合到一起被孤立，導致後端維護對於他們冗雜繁瑣的文件，是件收益很低的事情。沒有人喜歡做收益低的事情，只有提高了維護介面文件的收益，才能真正解決這個問題。
在介面開發過程中，後端通常都會使用 postman 等類似的工具測試介面，而測試介面是在開發過程中一個必要的過程。如果引數有改動，必然會在 postman 等工具上更新欄位和測試介面。由此可以聯想到， 如果能有一款工具既可用來做測試介面，又能作為介面文件工具，將介面文件和介面測試連線到一起，不就解決了此問題。YApi 解決方案是將介面文件和測試通過單一資料來源連線到一起，如果有改動，因為改的是單一的資料來源，就不會出現更新滯後和不及時問題。
- 前端 Mock Server 方案
資料 Mock 服務在開發前期是比較棘手的問題。大多數情況下，介面請求引數和返回資料都是後端規定的，在後端介面沒有完成之前，介面對於前端就是一個黑洞，可能最初對介面的定義跟實際後端做出的介面會有非常大的不同。這個時候就需要有一個工具，不僅能模擬真實介面的情況，還能關聯介面文件，在後端開發過程中，可以隨時調整介面定義，並通知給前端開發者改動資訊。
在 YApi 平臺，前後端只要維護介面定義的響應資料，就可以生成需要的模擬資料，下面這段程式碼定義了生成資料模板：
{
"errcode": 0,
"errmsg": "@string",
"data": {
"type":"@pick(1,2,3)",
"list|1-10": [{
"uid": "@id",
"username": "@name"
}]
}
}
複製程式碼可生成如下的模擬資料：
{
"errcode": 0,
"errmsg": "^*!SF)R",
"data": {
"type": 2,
"list": [
{
"uid": "370000200707276255",
"username": "Ruth Clark"
},
{
"uid": "650000200211185728",
"username": "Anthony Martin"
},
{
"uid": "370000199201143855",
"username": "Laura Rodriguez"
},
{
"uid": "610000198704072775",
"username": "Anthony Perez"
}
]
}
}
複製程式碼以往的資料 mock 方案難免會影響專案原始碼，yapi 使用了伺服器代理的方案，只需要在你的開發機做下伺服器反向代理配置，不用修改專案一行原始碼，即可獲取到所有的 mock 資料。
基礎的 Mock 工具已經能滿足大部分的需求了，但有些複雜場景是無法實現的。例如：當我做一個資料列表頁面，需要測試某個欄位在不同長度下以及資料為空時頁面互動。YApi 提供了期望和自定義指令碼的功能。
自定義指令碼
自定義指令碼可根據請求的引數，cookie 資訊，使用 javascript 指令碼自定義返回的資料。我們假設有個場景，我希望通過 cookie "_type" 控制列表頁面資料顯示，假設 _type 是 error，那麼列表顯示異常錯誤資訊；假設 _type 是 empty ，列表顯示為空。可使用下面程式碼實現：
if(cookie._type == 'error'){
mockJson.errcode = 400;
}
if(cookie._type == 'empty'){
mockJson.data.list = [];
}
複製程式碼3.自動化測試
介面開發完成後，後續的迭代是非常多的，每次對原始碼的修改，都需要大量的測試才能確保介面是否正確。人工判斷肯定是不好的，最好的辦法做成自動化測試，但自動化測試又是一件成本非常高的事情，需要後端人員和QA人員學習相關的框架，和寫大量的程式碼。
YApi 的目標是通過簡單的 GUI 介面，就算不懂程式開發，只需配置相關的引數和斷言語句，就能實現自動化測試，非常的易用。除了基本的功能外，YApi 還提供了強大的 Pre-Script 和視覺化表示式功能。
Pre-Script
Pre-Script 包括請求引數處理指令碼和響應資料處理指令碼兩部分。通過自定義 javascript 指令碼方式改變請求的引數和返回的 response 資料。他的使用場景如下：
- 介面請求引數需要加密及返回 response 解密
- 介面請求引數需要新增計算 token
視覺化表示式生成器
視覺化表達主要是為了方便使用者生成自動化測試所用到的引數，通過一個樹形選擇性，快速引用所依賴的引數值。在所有的需要測試的介面配置完成後，點選開始測試，就會按照指定的順序依次測試所有介面，測試完成後，可檢視測試報告。
4.外掛機制
業務的需求是層出不窮的，YApi 作為一個面向全國所有開發者的工具，不可能整合所有開發者需要的功能。我們參考了極簡產品設計理念，保持核心的簡潔性，通過靈活強大的外掛機制滿足各類業務的需求。目前YApi的第三方登入，swagger、postman 資料匯入等功能都是基於外掛機制實現。
成果
YApi 在公司內部去年十月份上線後，不到一週時間，就有超過 700 個開發加入並使用 YApi 管理介面。目前公司內部已有將近300個專案使用 YApi 管理，平均每天的介面 mock 次數超過了5000+。本著開源精神，讓 YApi 提高更多開發者的效率，我們的YApi 在 github 開源了，目前已有 1.6 k star，全國將近 500 家公司使用 YApi 管理他們的介面，包括一些大家耳熟能詳的公司，如百度，京東，連結，快手，藝龍，唯品會等等
訪問地址
- demo 站點：yapi.demo.qunar.com
- github: github.com/ymfe/yapi