YApi

https://github.com/YMFE/yapi

接下來會有一系列的文章，介紹 YApi 的使用方法。
如果你有遇到跟筆者一樣的問題

YApi 值得你擁有

現代化的專案，因為分工日趨專業和細緻，通常會採取前後端分離架構，
在前後端分離的前提下，後端工程師的日常工作，大多都在實作各種 API。

實作 API，一開始通常是簡單的，只要照著產品需求，按部就班實作。

1. 開出 API Endpoint
2. 接收 Request Input，寫一些商務邏輯，返回 Response Output
3. 恩！完成一支 API 了
4. 寫 API 文件
5. 3rd Party 輕鬆愉快使用

但現實世界，通常不會那麼愉快，

6. 需求變更了，API 實作需要更改
7. 趕著上線，要快點完成喔！
8. 恩！ 新 API 完成了
9. 3rd Party 接不上新的 API，開始各種開會
10. API 從開發到放棄 之 文件從來沒同步過

往往 6, 7, 8, 9, 10，才是現實世界常遇到的狀況。

筆者最近就遇到，趕進度中的產品，為了接 2 支外部 API，
花了團隊 2 個 RD，2 個禮拜的狀況，這成本真的是非常高！

原因就在於，這兩支外部 API 年代久遠，文件已經落後於現況，且不夠完整。
Request Input 該怎麼下？
Response Output 的資料是否正確？
都花了 RD 許多時間去 Try 和驗證！

只要有點年紀的 API，都很容易遇到這問題，
規格是規格，文件是文件，實作是實作！
我們的目標一樣，但是我們的終點不一樣。

YApi 平台可以說就是為了解決這個問題而生，
讓 API 的規格、文件、實作，融合再一起，不再分道揚鑣。

為了達成這一點，Yapi 有以下三點核心功能：

1. API SPEC 設定 (YApi 會透過 SPEC 生成文件)
2. API Mock Data Example
3. API 自動化測試 (YApi 透過統一的 SPEC 進行測試)

讓 API 的開發、文件、驗證(自動化測試) 這三方，成為一個閉環。

上述的，

1. 可以想象成 API 的活文件

2. 可以想象成 怎麼使用 API，given what input get what response

3. 用 YApi 的自動化測試 1 and 2

4. 用 3 寫的 testcase 來測試真正後端實作是否正確

5. 修改 api 規格，應該要先回去改 1 and 2

6. 3 才會跟著修正

7. 若沒有修改 1 and 2 ,直接改 後端 api 的 code，破壞性更新時，4 應該會炸掉

8. 乖乖回去改 1 2 3

可以看出，只要使用的好，這是個封閉循環

除了核心功能之外，Yapi 也提供了豐富的專案管理功能和彈性，

1. 專案和人員權限管理
2. API SPEC 制訂
3. API 文件產生
4. MOCK Request and Response Data
5. Mock API 生成
6. 自動化測試 TestCase TestSiute TestData TestScript
7. 測試報告管理
8. API 導入和導出
9. Plugin and Open API 提供客製化和跟第三方整合的彈性

在接下來的 YApi 系列文章中，筆者會透過實際演練，介紹相關功能。

參考資料：
https://github.com/YMFE/yapi
https://juejin.im/post/5acc879f6fb9a028c42e8822