隨著互聯(lián)網(wǎng)的發(fā)展，API變的至關(guān)重要。根據(jù)統(tǒng)計(jì)，目前市面上有上千萬的開發(fā)者，互聯(lián)網(wǎng)項(xiàng)目超過10億，保守統(tǒng)計(jì)涉及的 API 數(shù)量大約有 100 億。這么大基數(shù)的API，只要解決某些共有的痛點(diǎn)，將會(huì)是非常有意義的事情。我們總結(jié)了API管理方面的問題，發(fā)現(xiàn)與API相關(guān)的文檔，調(diào)試，測試和數(shù)據(jù)Mock 在工作中效率是非常低下的。

業(yè)務(wù)痛點(diǎn)

?

接口的維護(hù)管理非常耗時(shí)，大概占用了30%開發(fā)時(shí)間。后端程序員要維護(hù)對于他們?nèi)哂嗟奈臋n，前端程序員又因?yàn)楹蠖碎_發(fā)提供的文檔不準(zhǔn)確，導(dǎo)致浪費(fèi)了大量的時(shí)間。

接口的正確性和穩(wěn)定性很難保證，前端工程師為了處理各種數(shù)據(jù)異常情況，將會(huì)寫大量異常處理邏輯。傳統(tǒng)的接口自動(dòng)化測試成本非常高，開發(fā)一個(gè)接口可能只需要一天，但寫接口測試用例，需要花費(fèi)好幾天的時(shí)間。

對于前端程序員，在后端功能沒有開發(fā)完成之前，他們需要接口返回?cái)?shù)據(jù) Mock ，以便不影響開發(fā)進(jìn)度。傳統(tǒng)的數(shù)據(jù) mock 是把模擬數(shù)據(jù)寫到項(xiàng)目代碼里，這么做會(huì)帶來更多新的問題，首先后端程序員定義的接口隨著需求、架構(gòu)涉及隨時(shí)發(fā)生變化的，如果前端程序員完全按照最初的設(shè)計(jì)定義mock數(shù)據(jù)，將會(huì)和實(shí)際做出來的接口有很大的出入。

沒有一個(gè)標(biāo)準(zhǔn)化的流程統(tǒng)一處理，這個(gè)過程是非常分散的，需要配合非常多的工具，效率比較低。

市場產(chǎn)品調(diào)研

我們期望有一個(gè)完整的接口工具，協(xié)助開發(fā)人員在簡單易用的GUI界面調(diào)試，管理文檔和測試接口。于是開始尋找市面上類似產(chǎn)品，經(jīng)過一段時(shí)間的分析，最終我們找到了幾個(gè)比較有代表性的產(chǎn)品 Rap，Nei，Easy-Mock。同時(shí)我們按照自己的訴求列出了一些關(guān)鍵的特征：

?

Nei 是網(wǎng)易前端事業(yè)部的產(chǎn)品，在這些產(chǎn)品中算是做得比較好的， nei 專注做 saas 服務(wù)這塊，沒有開源版本。對于去哪兒內(nèi)部，肯定不會(huì)把公司機(jī)密的接口數(shù)據(jù)放到第三方平臺(tái)。

Rap 是阿里媽媽 MUX 團(tuán)隊(duì)2013年出的一款產(chǎn)品，從時(shí)間上看是同類產(chǎn)品中最早的。Rap 是后端工程師基于 java 開發(fā)的，如果想定制部分功能，還需要學(xué)習(xí) java，而我們部門大家對 java 都不熟悉。另一方面 Rap 沒有接口測試功能，而后端使用其他工具（postman， restlet）測試接口，前后端開發(fā)人員沒有使用的統(tǒng)一工具。

Easy-Mock 是大搜車無線團(tuán)隊(duì)出的一款產(chǎn)品，Easy-Mock 定位是接口數(shù)據(jù)的模擬，解決前端依賴后端接口數(shù)據(jù)的問題，在同類產(chǎn)品中 mock 服務(wù)做得比較好。Easy-Mock 專注于前端數(shù)據(jù)的模擬，但無法解決去哪兒現(xiàn)有的問題。

Rap 和 Easy-Mock 只是針對開發(fā)人員的單一工具，他們只關(guān)注了開發(fā)流程某一方面，并沒有站在全局的角度去解決問題，我們的目標(biāo)是整合接口開發(fā)過程中的工具。所以我們開始自主研發(fā)一個(gè)全新的接口管理平臺(tái)，我們希望它能夠提供接口文檔管理，接口數(shù)據(jù)模擬（Mock），接口調(diào)試，自動(dòng)化測試等功能，讓前后端接口相關(guān)的工作進(jìn)行的更加高效。這就是 YApi 接口管理平臺(tái)斐然由來。下面聊聊 YApi 是如何解決上述的痛點(diǎn)。

解決方案

1. 共同維護(hù)一份接口定義，打通各個(gè)環(huán)節(jié)

?

在后端開發(fā)接口過程中，開發(fā)和測試是必不可少的環(huán)節(jié)。如下圖所示，按以往的做法，接口文檔管理因?yàn)闆]有跟開發(fā)和測試整合到一起被孤立，導(dǎo)致后端維護(hù)對于他們?nèi)唠s繁瑣的文檔，是件收益很低的事情。沒有人喜歡做收益低的事情，只有提高了維護(hù)接口文檔的收益，才能真正解決這個(gè)問題。

在接口開發(fā)過程中，后端通常都會(huì)使用 postman 等類似的工具測試接口，而測試接口是在開發(fā)過程中一個(gè)必要的過程。如果參數(shù)有改動(dòng)，必然會(huì)在 postman 等工具上更新字段和測試接口。由此可以聯(lián)想到， 如果能有一款工具既可用來做測試接口，又能作為接口文檔工具，將接口文檔和接口測試連接到一起，不就解決了此問題。YApi 解決方案是將接口文檔和測試通過單一數(shù)據(jù)源連接到一起，如果有改動(dòng)，因?yàn)楦牡氖菃我坏臄?shù)據(jù)源，就不會(huì)出現(xiàn)更新滯后和不及時(shí)問題。

?

1. 前端 Mock Server 方案

數(shù)據(jù) Mock 服務(wù)在開發(fā)前期是比較棘手的問題。大多數(shù)情況下，接口請求參數(shù)和返回?cái)?shù)據(jù)都是后端規(guī)定的，在后端接口沒有完成之前，接口對于前端就是一個(gè)黑洞，可能最初對接口的定義跟實(shí)際后端做出的接口會(huì)有非常大的不同。這個(gè)時(shí)候就需要有一個(gè)工具，不僅能模擬真實(shí)接口的情況，還能關(guān)聯(lián)接口文檔，在后端開發(fā)過程中，可以隨時(shí)調(diào)整接口定義，并通知給前端開發(fā)者改動(dòng)信息。

在 YApi 平臺(tái)，前后端只要維護(hù)接口定義的響應(yīng)數(shù)據(jù)，就可以生成需要的模擬數(shù)據(jù)，下面這段代碼定義了生成數(shù)據(jù)模板：

{"errcode": 0,"errmsg": "@string","data": {"type":"@pick(1,2,3)","list|1-10": [{"uid": "@id","username": "@name"}]}
}

可生成如下的模擬數(shù)據(jù)：

{"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"}]}
}

以往的數(shù)據(jù) mock 方案難免會(huì)影響項(xiàng)目源碼，yapi 使用了服務(wù)器代理的方案，只需要在你的開發(fā)機(jī)做下服務(wù)器反向代理配置，不用修改項(xiàng)目一行源代碼，即可獲取到所有的 mock 數(shù)據(jù)。

基礎(chǔ)的 Mock 工具已經(jīng)能滿足大部分的需求了，但有些復(fù)雜場景是無法實(shí)現(xiàn)的。例如：當(dāng)我做一個(gè)數(shù)據(jù)列表頁面，需要測試某個(gè)字段在不同長度下以及數(shù)據(jù)為空時(shí)頁面交互。YApi 提供了期望和自定義腳本的功能。

自定義腳本

自定義腳本可根據(jù)請求的參數(shù)，cookie 信息，使用 javascript 腳本自定義返回的數(shù)據(jù)。我們假設(shè)有個(gè)場景，我希望通過 cookie "_type" 控制列表頁面數(shù)據(jù)顯示，假設(shè) _type 是 error，那么列表顯示異常錯(cuò)誤信息；假設(shè) _type 是 empty ，列表顯示為空?？墒褂孟旅娲a實(shí)現(xiàn)：

if(cookie._type == 'error'){mockJson.errcode = 400;
}if(cookie._type == 'empty'){mockJson.data.list = [];
}

3.自動(dòng)化測試

接口開發(fā)完成后，后續(xù)的迭代是非常多的，每次對源碼的修改，都需要大量的測試才能確保接口是否正確。人工判斷肯定是不好的，最好的辦法做成自動(dòng)化測試，但自動(dòng)化測試又是一件成本非常高的事情，需要后端人員和QA人員學(xué)習(xí)相關(guān)的框架，和寫大量的代碼。

YApi 的目標(biāo)是通過簡單的 GUI 界面，就算不懂程序開發(fā)，只需配置相關(guān)的參數(shù)和斷言語句，就能實(shí)現(xiàn)自動(dòng)化測試，非常的易用。除了基本的功能外，YApi 還提供了強(qiáng)大的 Pre-Script 和可視化表達(dá)式功能。

Pre-Script

Pre-Script 包括請求參數(shù)處理腳本和響應(yīng)數(shù)據(jù)處理腳本兩部分。通過自定義 javascript 腳本方式改變請求的參數(shù)和返回的 response 數(shù)據(jù)。他的使用場景如下：

• 接口請求參數(shù)需要加密及返回 response 解密
• 接口請求參數(shù)需要添加計(jì)算 token

可視化表達(dá)式生成器

可視化表達(dá)主要是為了方便用戶生成自動(dòng)化測試所用到的參數(shù)，通過一個(gè)樹形選擇性，快速引用所依賴的參數(shù)值。在所有的需要測試的接口配置完成后，點(diǎn)擊開始測試，就會(huì)按照指定的順序依次測試所有接口，測試完成后，可查看測試報(bào)告。

4.插件機(jī)制

業(yè)務(wù)的需求是層出不窮的，YApi 作為一個(gè)面向全國所有開發(fā)者的工具，不可能集成所有開發(fā)者需要的功能。我們參考了極簡產(chǎn)品設(shè)計(jì)理念，保持內(nèi)核的簡潔性，通過靈活強(qiáng)大的插件機(jī)制滿足各類業(yè)務(wù)的需求。目前YApi的第三方登錄，swagger、postman 數(shù)據(jù)導(dǎo)入等功能都是基于插件機(jī)制實(shí)現(xiàn)。

成果

YApi 在公司內(nèi)部去年十月份上線后，不到一周時(shí)間，就有超過 700 個(gè)開發(fā)加入并使用 YApi 管理接口。目前公司內(nèi)部已有將近300個(gè)項(xiàng)目使用 YApi 管理，平均每天的接口 mock 次數(shù)超過了5000+。本著開源精神，讓 YApi 提高更多開發(fā)者的效率，我們的YApi 在 github?開源了，目前已有 1.6 k star，全國將近 500 家公司使用 YApi 管理他們的接口，包括一些大家耳熟能詳?shù)墓?#xff0c;如百度，京東，鏈接，快手，藝龍，唯品會(huì)等等