Alan Tsai 的學習筆記

分支(branch)可以説是git的殺手鐧功能，透過建立分支就像使用多重影分身之術一樣，可能同時進行不同分支的開發，最後可以透過合并(merge)把所有的修改整合在一起。

不過開啓大量分支有一個缺點，那就是當合并成功之後，怎麽清理不需要的分支。

這篇就來看看怎麽快速清理掉這些無用的"分身"。

在上一篇([apiary][05]設計API時好用的工具 - 讓前後端溝通格式不再卡卡 - MSON格式篇)介紹完了MSON之後，基本上要寫出一個API格式的文件就沒什麽問題。

當API定義出來了之後，Apiary會自動建立出一個mock server，前端這個時候就可以呼叫這個mock server做初步的開發。

同時間，後端就可以依照定義好的API文件開始去開發。

理論上來説，只要前端和後端都依照同一份開發，那麽最後只需兩邊好了的時候做一個整合測試，那麽整體功能就完成了。

這篇來看看前端呼叫mock server的方式。

在上一篇([apiary][04]設計API時好用的工具 - 讓前後端溝通格式不再卡卡 - API Blueprint Actions格式篇)介紹了如何定義Actions，換句話説，以目前的知識要定義出一個API已經沒有什麽問題了。

但是在上一篇還有遇到一個問題，那就是不管是request或者response的JSON物件沒有定義出來裡面的欄位以及説明。換句話説，目前的方式只有範例，但是每一個欄位的形態，描述沒有辦法定義。

Apiary團隊當初考慮到了這一個問題，因此建立出一個格式稱之爲Markdown Syntax for Object Notation (MSON)，專門用來描述JSON以及JSON Schema。

這邊來看看MSON怎麽使用。

在上一篇 ([apiary][03]設計API時好用的工具 - 讓前後端溝通格式不再卡卡 - API Blueprint基本結構介紹篇) 瞭解了整個API Blueprint的基本結構之後，對於整個文件的架構應該有個比較充分的瞭解了。

但是上一篇因爲篇幅的關係，跳過了Actions裡面定義的部分。

Actions是什麽呢？基本上Actions就在定義某一之API可以接受的Request和Response是什麽。

這篇來看看怎麽定義。

在上一篇 ([apiary][02]設計API時好用的工具 - 讓前後端溝通格式不再卡卡 - 工具使用介紹篇) 瞭解了怎麽使用apiary這一個工具來撰寫api的文件之後。

在這一篇將來實際的撰寫看看感覺如何。

之前提到過apiary預設的文件格式是API Blueprint，因此這一篇將來看看API Blueprint怎麽使用，並且看看撰寫起來感覺如何。

在上一篇([apiary][01]設計API時好用的工具 - 讓前後端溝通格式不再卡卡 - 概念介紹篇)介紹完了，讓前後端能夠溝通順暢的幾種API文件化的語言，以及爲什麽選擇Apiary (API Blueprint)之後。

這一篇將來看看怎麽使用Apiary。將會以整個功能開始介紹起，讓大家先熟悉這個工具，也避免之後使用上面遇到一些奇奇怪怪的問題。

近幾年前端爆炸式的成長，前後端分離的架構也越來越常見，如果前端和後端的開發者不是同一個人的時候，怎麽樣讓並行開發可以變得容易就非常的重用。

很長遇到一個問題是，前端開發者和後端開發者在API的内容以及格式有落差導致兩邊不好並行開發。

接下來的幾篇文章將要介紹Apiary這個工具，透過這個工具可以讓兩邊溝通沒有落差，並且可以同時進行開發。

這篇先從爲什麽選擇Apiary做開始，市面那麽多種，爲什麽要選Apiary，和其他方案比起來有什麽好處。

先從前後端開發問題看起，以及爲什麽Apiary (API Blueprint)是最適合的解決方案。