一、目标
建設一個高效、易用且經濟實惠的API管理平台，滿足API的建立、管理、測試、文檔管理和權限管理需求，并支援第三方API工具導入，以提升項目多系統、多服務API使用效率和團隊協作效率。
二、現存問題：
- API測試覆寫率低，隻在接口研發完成時做少量本地測試。
- 由于業務邏輯變更，早期開發的接口可能報錯或失效。
- 代碼無法持續重構與演進，因為擔心影響業務邏輯。
三、需求分析
- 易用性： 快速生成或批量導入接口定義和入參定義，支援持續內建。
- 可擴充性： 接口入參可配置，可以自定義Header、Cookie資訊。
- 測試報告： 支援自動化測試，生成測試報告，并能持續內建。
- 資料模拟（Mock）： 前端開發人員可以根據接口定義配置Mock Server進行并行開發。
- 持續內建： 開發人員合并代碼時，自動觸發接口測試，確定主流程不受影響。
- 個性化需求： 支援前置與後置代碼編寫，滿足不同團隊的個性化需求。
- 多系統一體化： 支援多個系統的API內建在一個平台。
四、技術選型和對比分析
1、選擇标準
我們的需求，找到一款開源、廣泛使用、能無縫對接Swagger、smart-doc規範（不用手工定義一個個接口），支援自動化測試流程、對前端支援Mock資料的工具。
2、篩選
在目前API管理平台的海量選擇中，一些有着廣大使用者群和良好口碑的平台分外引人注目，例如Apifox、APIPost、Swagger、YAPI、Eolinker和EasyAPI等等。然而，考慮到開源認證與合規風險，我們必須對選擇進行審慎考慮。
對于國外的産品，由于可能存在的合規風險和其它問題，我們的選擇焦點僅集中在了最為老牌且知名的Swagger上，而其它的都被逐一排除。同時，如果産品采用了GNU AGPLv3和商業許可的雙重授權方式，我們也直接将其排除在選擇範圍之外，以避免後續可能的法律糾紛。
在經過這些篩選後，我們最終收集到了8款滿足條件的API管理平台。在對這些平台進行初步了解和簡單操作後，我們發現這些平台不僅功能強大，同時也各有其獨特的特色和優勢。
但是，為了進一步提煉我們的選擇，并找到最适合我們需求的平台，我們決定引入更多的篩選條件，并采用積分制進行評估。具體的評分标準如下：免費私有部署（5分）、團隊協作能力（0-3分）、工作流覆寫能力（0-7分）、學習成本（1-2分）以及其它擴充功能（0-2分）。通過這種方式，我們期待能夠更精确、更有效地找到我們團隊的最佳選擇。
| api管理平台 | 私有 <5> | 調試 <1> | mock<1> | 項目管理<1> | 團隊協作<3> | 測試用例<2> | 自動化測試<1> | 性能測試<1> | 複雜度<2> | 代碼生成<1> | 擴充工具<1> | 定位<1> | 綜合分 |
| wiki | 是 | 無 | 無 | 無 | 無 | 無 | 無 | 無 | 簡單 | 無 | 無 | 開發 | 7 |
| postman | 是 | 是 | 支援 | 類同 | 無 | 強 | 支援 | 無 | 普通 | 支援 | 無 | 測試 | 13 |
| apifox | 收費 | 是 | 支援 | 支援 | 強 | 強 | 支援 | 支援 | 普通 | 支援 | 支援 | 團隊 | 14 |
| apipost | 收費 | 是 | 支援 | 支援 | 強 | 強 | 支援 | 無 | 普通 | 支援 | 支援 | 團隊 | 13 |
| swagger | 是 | 是 | 支援 | 支援 | 普通 | 弱 | 無 | 無 | 普通 | 支援 | 無 | 開發 | 12 |
| yapi | 是 | 是 | 支援 | 支援 | 較強 | 較強 | 支援 | 無 | 普通 | 支援 | 支援 | 團隊 | 17 |
| eolinker | 收費 | 是 | 支援 | 支援 | 強 | 強 | 支援 | 支援 | 普通 | 支援 | 支援 | 團隊 | 14 |
| metersphere | 是 | 是 | 支援 | 類同 | 強 | 強 | 支援 | 支援 | 普通 | 支援 | 無 | 測試 | 17 |
| rap | 是 | 是 | 支援 | 支援 | 普通 | 無 | 無 | 無 | 簡單 | 支援 | 無 | 開發 | 12 |
| easyapi | 是 | 是 | 支援 | 類同 | 普通 | 無 | 無 | 無 | 簡單 | 無 | 無 | 開發 | 11 |
能否免費私有化部署是重要考量，直接給了5分。在此前提下，yapi和metersphere以17分并列第一。下面将着重介紹和比較這兩個平台。
五、yapi介紹
yapi提供了比較友善的安裝部署方法，但是在nodejs和npm版本選擇上，有坑。用最新版本竟然不支援。目前用的nodejs是v13.14.0，npm是v6.14.4，整個系統都點了一遍，tag這個小功能還是有點小問題，不過tag我們暫時也不用，沒影響。期待後續版本解決吧。
1、主界面，UI體驗不錯。
2、系統資訊，統計項夠用
3、項目首頁，包含接口清單、動态、資料管理、成員管理、設定、wiki。
4、接口能直接在web中調試，而且這個調試頁面的所有修改可以儲存，并同步更新接口和對應用例（僅路徑）
5、測試集合，這裡可以把指定接口或全部接口一鍵轉化成用例集。每個用例可以執行、克隆、斷言(僅自動化時生效)等。用例的編寫還是比較友善的。但是用例的管理上就比較弱了，隻支援一層目錄。不過項目的分的細一些，影響也不大。整體使用感覺，非常類似于postman，上手應該沒難度。
6、mock，針對每個接口可以設定mock，可以設定多個期望，也支援腳本。無論前端還是測試，應該都可以快速上手使用。
可惜的是，頁面上無法生成類似于mock_client之類的本地運作的mock檔案，後續我查查有沒有相關插件工具可以支援。
7、用例集裡面，直接點選開始測試，則頁面開始逐個執行用例。也支援”服務端測試“，就是在其它伺服器執行這些用例。具體操作方法大家可自行體會。
一次隻能執行一個用例集，不支援一次執行多個用例集。而且，沒有精美的測試報告。整體來說，接口測試相關功能，夠用的程度。後續查查有沒有相關插件工具，增強測試報告的能力。
8、導入導出，支援swagger、postman、json、HAR導入，其中postman格式非常可惜隻支援V1版本的，目前較新版本的postman都隻能導出V2和V2.1的json檔案了。
導出，支援html、MD、swaggerjson、json，相信夠用了。
六、MeterSphere介紹
MS的部署非常簡單，一個sh腳本，執行後就等着就行了。這點做的不錯。部署完後增加了msctl這個運維指令，可以非常友善的啟動、關閉、檢視整個MS系統。
1、主界面，顔值不錯。内容明顯多于yapi，而且明顯偏重于測試支撐。
2、接口測試這裡，包含首頁、接口定義、接口自動化、測試報告。其中接口定義，是用來導入和維護api文檔的，路徑有點深啊。
3、界面略顯淩亂，控件有點錯位，其它頁面也有類似的情況。應該是分辨率的問題，大一些分辨率應該就行了。
對接口的維護、調試、mock，都具備，操作項簡單明了。前端開發、後端開發用起來上手快。
不過也沒法生成類似于mock_client的本地執行檔案。也沒有插件支援。
4、每個api，都可以調試、mock、用例。而且Metersphere對用例的管理思路，跟yapi不一樣，它的每個用例都關聯到接口的，即每個接口下挂若幹個用例，然後所有用例可以自由歸屬集合和場景。對于測試工作的支撐非常強大。
還有單獨的用例子產品，可以清單，也可以系統内直接畫腦圖
5、接口自動化測試，以”場景“為基礎，除了最簡單的依次執行所有用例，也可以通過配置各種控制器，模拟業務流。功能強于postman的參數傳遞邏輯。
6、ms有簡單但夠用的測試報告
7、可選1個或幾個測試用例，直接轉到性能測試子產品。ms安裝的時候自帶了jmeter，隻要配置好資源池，這裡就自動調用jmeter進行壓力測試。
8、還能進行UI測試和UI自動化測試，但這個是企業版功能，免費版無法使用。且這個導航無法去掉。有點小别扭了。
七、總結
Yapi和MeterSphere兩者都是優秀的API管理平台，提供了強大的功能和良好的使用者體驗。初步看來，Yapi和MeterSphere的功能和性能似乎相差無幾。然而，當我們深入研究這兩個平台的商業化政策、團隊規模、可替代功能、學習和維護成本、未來替換公司自有平台難度、開發人員訪談和合規風險時，我們發現兩者的定位和複雜度是完全不同的。
| 對比項 | yapi | Metersphere |
| 商業版本 | 無 | 有 |
| 免費版本 | 有，無限制 | 有，有限制 |
| 部署 | 無難度 | 無難度，且一鍵部署 |
| 資料導入 | 支援豐富 | 支援豐富 |
| 資料導出 | 支援豐富 | 隻有自有格式和swagger |
| 開發用 | 完全夠用 | 完全夠用 |
| 自動生成文檔 | 支援，無侵入 | 不支援 |
| 前端用 | 夠用，簡單 | 夠用，簡單，但路徑有點深 |
| 測試用 | 夠用，簡單 | 非常強大，但有收費功能 |
| 項目管理 | 夠用，簡單 | 能支撐大項目，操作稍多 |
| 人員管理 | 扁平化 | 三級權限，劃分細緻 |
| 學習難度 | 簡單，基本顧名思義 | 普通，需要文檔支援 |
| 維護難度 | 簡單 | 簡單，但路徑有點深 |
| 報表統計 | 少 | 豐富 |
| 消息管理 | 少 | 豐富 |
| 流程覆寫 | 後端+前端+測試 | 後端+前端+測試，偏測試 |
| 擴充工具 | 少 | 無 |
在下面的内容中，我們将詳細分析每個次元的對比結果，以更好地了解這兩個平台的差異，并找出最适合我們團隊的API管理平台。
- 定位和複雜度： 初步看起來，Yapi和MeterSphere的功能似乎差不多，但如果細緻研究它們的商業化政策，會發現它們的定位和複雜度有着顯著的差異。Yapi注重API的管理和協作，它的使用者界面更加直覺，讓使用者能夠輕松地進行API管理。相比之下，MeterSphere則定位為一站式的企業級開放源代碼平台，它更注重測試生命周期的全面覆寫，其功能更為複雜和全面。
- 團隊規模： 根據目前團隊的規模，選擇更合适的工具是非常重要的。Yapi由于其簡潔和直覺的界面，對于小型團隊來說更容易接受和使用。而MeterSphere的功能覆寫度較廣，可能需要較大的團隊去進行管理和維護。
- 可替代功能和學習維護成本： Yapi的功能比MeterSphere來得簡單，學習和維護成本相對較低。然而，MeterSphere作為一站式解決方案，提供了更多的可替代功能，可能需要更多的時間去學習和維護。
- 未來替換公司自有平台難度： 若考慮到未來可能會替換公司現有的API管理平台，Yapi由于其簡潔的設計和較低的學習成本，将更容易為團隊接受。
- 開發人員訪談： 經過與多個業務部門開發人員和集團其他業務人員的訪談，我們發現大多數開發人員更傾向于使用Yapi，他們認為Yapi更易于使用和管理。
- 合規風險： Yapi是由國内團隊開發的國産軟體，采用Apache License 2.0，這是一種寬松且無傳染性的開源證書。許多國内大廠都在使用Yapi，而且我們也查閱了公司的技術貨架，發現Yapi被推薦使用。是以，Yapi無合規風險。
綜上所述，我們最終推薦使用Yapi作為我們中台組的API管理平台。此外，我們還了解到，集團的其他業務組也在使用Yapi。
注：經過安全漏洞掃描中，發現Yapi漏洞，可修複
具體修複方案如下：
- 關閉使用者注冊功能：在"config.json"添加"closeRegister:true"配置項： { "port": "*****", "closeRegister":true } 修改完成後，重新開機 YApi 服務。
- 暫時關閉 mock 功能：（需要修改 YApi 代碼）； 在"config.json"中添加 "mock: false" ； 在"exts/yapi-plugin-andvanced-mock/server.js"中找到if (caseData && caseD ata.case_enable) {…}，在其上方添加if(!yapi.WEBCONFIG.mock) {return false;}。
- 檢查使用者清單，删除惡意不明使用者；如果發現存在不明使用者建立的接口及 mock 腳本請及時上報資訊安全管理部。