如何設計優秀的API（轉）

到目前爲止，已經負責API接近兩年了，這兩年中發現現有的API存在的問題愈來愈多，但不少API一旦發佈後就再也不能修改了，即時升級和維護是必須的。一旦API發生變化，就可能對相關的調用者帶來巨大的代價，用戶須要排查全部調用的代碼，須要調整全部與之相關的部分，這些工做對他們來講都是額外的。若是辛辛苦苦完成這些之後，還發現了相關的bug，那對用戶的打擊就更大。若是API常常發生變化，用戶就會失去對提供方失去信心，從而也會影響目前的業務。

可是咱們爲何還要修改API呢？爲了API看起來更加漂亮？爲了提供更多功能？爲了提供更好的性能？仍是僅僅以爲到了改變了時候了？對於用戶來講，他們更願意使用一個穩定可是看起來不那麼時髦的API，這並不意味着咱們再也不改進API了。當糟糕的API帶來的維護成本愈來愈大時，我想就是咱們去重構它的時候。

若是能夠回頭從新再作一遍，那麼我心目中的優秀的API應該是怎麼樣的？

判斷一個API是否優秀，並非簡單地根據第一個版本給出判斷的，而是要看隨着時間的推移，該API是否還能存在，是否仍舊保持得不錯。槽糕的API接口各類各樣，可是好的API接口對於用戶來講必須知足如下幾個點：

• 易學習：有完善的文檔及提供儘量多的示例和可copy－paste的代碼，像其餘設計工做同樣，你應該應用最小驚訝原則。
• 易使用：沒有複雜的程序、複雜的細節，易於學習；靈活的API容許按字段排序、可自定義分頁、 排序和篩選等。一個完整的API意味着被指望的功能都包含在內。
• 難誤用：對詳細的錯誤提示，有些經驗的用戶能夠直接使用API而不須要閱讀文檔。

而對於開發人員來講，要求又是不同的：

• 易閱讀：代碼的編寫只須要一次一次，可是當調試或者修改的時候都須要對代碼進行閱讀。
• 易開發：個最小化的接口是使用盡量少的類以及儘量少的類成員。這樣使得理解、記憶、調試以及改變API更容易。

如何作到以上幾點，如下是一些總結：

1.面向用例設計

若是一個API被普遍使用了，那麼就不可能瞭解全部使用該API的用戶。若是設計者但願可以設計出被普遍使用的API，那麼必須站在用戶的角度來理解如何設計API庫，以及如何才能設計出這樣的API庫。

2.採用良好的設計思路

在設計過程當中，若是能按照下面的方式來進行設計，會讓這個API生命更長久

• 面向用例的設計，收集用戶建議，把本身模擬成用戶，保證API設計的易用和合理
• 保證後續的需求能夠經過擴展的形式完成
• 初版作儘可能少的內容，因爲新需求能夠經過擴展的形式完成，所以儘可能少作事情是抑制API設計錯誤的一個有效方案
• 對外提供清晰的API和文檔規範，避免用戶錯誤的使用API，尤爲是避免API（見第一節）靠後級別的API被用戶知曉與誤用

除此以外，下面還列出了一些具體的設計方法：

• 方法優於屬性
• 工廠方法優於構造函數
• 避免過多繼承
• 避免因爲優化或者複用代碼影響API
• 面向接口編程
• 擴展參數應當是便利的
• 對組件進行合理定位，肯定暴露多少接口
• 提供擴展點

3.避免極端的意見

在設計API的時候，必定要避免任何極端的意見，尤爲是如下幾點：

• 必須漂亮（API不必定須要漂亮）
• API必須被正確地使用（用戶很難理解如何正確的使用API，API的設計者要充分考慮API被誤用的狀況：若是一個API可能會被誤用，那麼它必定會被誤用）
• 必須簡單（咱們總會面臨複雜的需求，能二者兼顧的API是更好的API）
• 必須高性能（性能能夠經過其餘手段優化，不該該影響API的設計）
• 必須絕對兼容（儘管本文一直提到如何保證兼容，可是咱們仍然要意識到，一些極少狀況下會遇到的不兼容是能夠容忍的）

4.有效的API評審

API設計完成之後，須要通過周密的設計評審，評審的重點以下：

• 用例驅動，評審前必須提供完善的使用用例，確保用例的合理性和完備性。
• 一致性，是否與系統中其餘模塊的接口風格一致，是否與對稱接口的設計一致。
• 簡單明瞭，API應該簡單好理解，容易學習和使用的API纔不容易被誤用，給咱們帶來更多的麻煩。
• API儘量少，若是一個API能夠暴露也能夠不暴露，那麼就不要暴露他，等到用戶真正有需求的時候再將它成爲一個公開接口也不遲。
• 支持持續改進，API是否可以方便地經過擴展的方式增長功能和優化。

5.提升API的可測試性

API須要是可測試的，測試不該依賴實現，測試充分的API，尤爲是通過了嚴格的「兼容性整合測試」的API，更能保證在升級的過程當中不出現兼容性問題。兼容性整合測試，是指一組測試用例集合，這組測試用例會站在使用者的立場上使用API。在API升級之後，再檢測這組測試用例是否能徹底符合預期的經過測試，儘量的發現兼容性問題。

6.保證API的向後兼容

對於每個API的設計者來講，都渴望作到「向後兼容」，由於不論是如今的API用戶，仍是潛在的API用戶，都只信任那些可兼容的API。但向後兼容有多個層次上的意義，並且不一樣層次的向後兼容，也意味着不一樣的重要性和複雜度。

7.保持逐步改善

過去咱們總但願能將現有的「不合理」的設計徹底推翻，而後按照如今「美好」的思路，從新設計這個API，可是在一段時間之後，又會碰到同樣的情況，須要再推翻一次。 若是咱們沒有有效的逐步改善的辦法，依靠推翻現有設計，從新設計API只能讓咱們回到起點，而後重現以前的過程。 要有一套行之有效的持續改善的辦法來在API兼容的同時，改善API使之更好。

8.把握API的生命週期

每個API都是有生命週期的，咱們須要讓API的生命週期更長，而且在API的生命週期結束時能讓其平滑的消亡。

• 告訴用戶咱們是如何設計的，避免誤用，提供指導，錯誤的使用每每是縮短API壽命的一大殺手
• 提供試用期，API不可能一開始就是穩定，通過試用的API纔能有更強的生命力
• 爲API分級：內部使用；二次開發使用；開發或試用中；穩定；棄用API。避免API被濫用的同時，咱們能夠經過調整API的級別，來擴大其影響力，也能更優雅的結束一個API的生命週期。

開發API的過程其實就是一個溝通交流的過程。溝通的雙方就是API用戶和API設計者。

9.一些具體的實施方案

在一個API不可避免要消亡或者改變的時候，咱們應該接受而且面對這個事實，下面列舉了幾種保證兼容性的前提下，對API進行調整的辦法：

• 將API標記爲棄用，從新創建一個新的API。若是一個API不可避免要被消亡，這是惟一的辦法。
• 爲其添加額外的參數或者參數選項來實現功能添加
• 將現有API拆成兩部分，提供一個精簡的核心API，過去的API經過封裝核心API上實現。這一般用於解決用戶須要一個代碼精簡的版本時。
• 在現有的API基礎上進行封裝，提供一個功能更豐富的包或者類

一些好的API示例：Flickr API，這裏是文檔的示例，同時提供了一個很是方便的API測試工具。

• Mediawiki API
• Ebay API，這裏有一個很是詳盡的文檔示例。

引用地址：http://www.biaodianfu.com/how-to-design-a-good-api.html