Apiary 是個讓我們撰寫 API 規格的服務，但不僅如此，依照 Apiary 特有的 Markdown 語法寫下的 API 規格文件，Apiary 會根據規格文件幫我們產出文件與假資料的接口，本文介紹一下它的一些特色。
費用方案
在入坑前一定要先了解他的費用，避免愛上後難以自拔。
Apiary 目前有免費與收費的方案，在它的網站上可以查到每個方案的差異，不過必須特別提醒的是，Apiary 已經被甲骨文收購，並併入台灣沒什麼人用的 Oracle Cloud 產品線內，未來會不會依舊保持獨立的服務是有疑問的，另外就是甲骨文一貫的…作風，如果對甲骨文特別有疑慮的請自行斟酌使用。
Apiary
回歸正題，Apiary 解決了我們以往在開發 API 時的痛點：
- 規格文件先寫出來，但 API 還沒有完工，導致無法測試，只能先略過或是假裝 API 是好的來做測試，簡稱瞎測。
- API 已經寫了，但沒空寫文件，導致串接參數像秘方一樣只能靠口耳相傳，比較邊緣的同事就難以實做串接，最後因為文件一直與實做脫節，導致產品難以維護。
- 有 API 也有文件，但不知道為何就是串不起來，不確定 API 寫錯還是文件寫錯，總之難免有錯。
API Blueprint
前面提到過在 Apiary 撰寫文件必須使用它特規的 Markdown 語法，這種 Markdown 的變體有自己的名字 API Blueprint。
API Blueprint 的語法以 Markdown 為基礎，只是加了一些為 API 文件需求而生的語法格式。
API Blueprint 有兩種型式，一種用於定義資料結構，例：
# Data Structures
## Blog Post (object)
+ id: 42 (number, required)
+ text: Hello World (string)
+ author (Author) - Author of the blog post.
## Author (object)
+ name: Boba Fett
+ email: fett@intergalactic.com
應該可以望文生義。
有了資料結構後，就可以把前面定義的資料結構用於 API 定義文件內，例：
# Blog Posts [/posts]
## Retrieve All Posts [GET]
+ Response 200 (application/json)
+ Attributes (array[Blog Post])
API Blueprint 的語法相較於另一派的 XML 或 JSON 都更簡單。
規格文件與假接口
用 API Blueprint 寫好定義文件後，Apiary 會依照文件內的定義，產生出 API 文件與假接口，具體範例可以參考這份官方範例 Sample API Documentation，裡面所有的 API 接口都是可以被使用的。
其它值得一提的功能
除了文件與接口外，另外值得一提的是 Apiary 支援 GitHub Sync，我們可以把 API 定義文件也放到程式專案資料夾內，享受版控的好處，同時透過 GitHub Sync 的機制，每次提交都會觸發 Apiary 也把發布的規格文件更新，好棒棒。
Top comments (0)