根據CA公司在2018年末的市場研究報告顯示，API化、微服務和容器是企業現代應用架構的三大發展方向。關於後兩者，本座在之前的好幾期文章中都已探討過了。而“API化”看似一個及其技術的標準，如何能成為應用架構的發展趨勢，當下國內商業銀行大搞Open API的寓意何在，本座今天來跟大夥探討下“API化”的課題。
近年來各行各業都在講能力輸出，賦能生態，早年我們可能理解這些能力是現場指導，人員外包的方式，現在更多的是通過系統對接，數據傳輸的方式將內部能力外化，助力生態夥伴。當然在這個過程中，能力輸出方一定不希望將代碼邏輯、底層數據和盤托出，其實用戶也不關心這些，他們只關注需要輸入的字段是不是能得到預期的結果，就像我們打開手機地圖查定位時並不關注App背後有的是基站定位還是衛星定位，只要結果準確就行。
上面說的這些內容大致就是API的功能了，從商業角度保護服務提供方隱私且精準應對客戶需求，從技術角度如何設計一款易懂好用的API呢？我們以獲取微信群群主的功能為例（這其實是一個開放的接口，去年有關部門不是約談了很多群主嘛0），請求的報文格式是getAdmins (string ) 。getAdmins是微信群組的一個Method類，接入方的需求很簡單，最多再加上返回兩個錯誤碼“該群組不存在”以及“該群組已刪除”。
在設計這樣一個API時，需要考慮到以下三點：
命名：Method類應儘量簡單易懂，getAdmins加群組ID，使用戶一看便知道是獲取群組所有管理員的指令，而不應該返回創建者或全體用戶，而且類似的指令（getCreator和getUsers）以後會有對應的API，因此好的API需要設計人員在一開始就界定好完整的命名規則。
參數定義：作為一款面向市場的產品，開發人員不能苛求終端用戶熟悉API的全套參數，因此很多情況下我們把最淺顯的參數暴露給客戶，而將複雜的參數內部消化了，客戶只看得到輸入的群組名稱和返回的管理員列表，中間的參數轉換，服務間的調用都在內部系統之間完成了。
響應對象：除了告知用戶管理員ID之外，還需要響應哪些信息呢？這是程序員之間的默契大考驗，作為調用方，我可能希望獲得的ID字段入庫回頭找他們約談，我想知道ID的字段類型應該設成啥？長度是多少？或者在錄入失敗的時候最好能詳細提示我究竟是什麼原因。因此一個好的響應會將各種報錯展示得很清楚，分主返回碼和次級返回碼，當然如果能提供詳細的接口文檔自然是最好。
在設計API時應儘量考慮簡單，有些初級程序員喜歡將所有Method都放到請求報文中，再拿上面的例子來說，一個請求的報文（JSON）最好是：
{"groupID": "123"}，而不是{"action": "getAdmin"; "groupID": "123"}，因為getAdmin會體現在調用方發起的指令裡，而不是請求的正文裡。
伴隨著企業微服務的深入，架構上不允許在一個應用開發中包含所有業務邏輯，不然會帶來服務的緊耦合，不光資源不能獨立分配，集成測試，系統運維都會牽一髮而動全身。
以上只是get調用的形式，至於其他（例如post，put等）調用方式還需要考慮數據量大小（是否需要做分頁或分片傳輸），緩存策略與一致性校驗等等的問題，這都需要企業級架構師進行全盤統籌。