如何設計優秀的 API

jopen 12年前發布 | 9K 次閱讀 API

API 的設計是編程中最困難的事情。甚至有人認為,哪怕你已經有著十年的相關經驗,也僅僅只能接觸嘗試 API 的設計。我們也曾經或多或少的為了那些缺乏經驗的程序員所設計的一些 API 吃了苦頭。然而,如果你能在這個過程中獲得了一位優秀的導師對你進行指點,那么你的進步會呈幾何速度提升。

本文作者就從他的導師那學會了一套不受框條約束的方法,稱之為“90-9-0.9”,可能最難的還是剩下的那0.1。原文內容如下:

幸運的是,在剛剛走出大學校門時,我加入 Atalasoft。這是一間專門設計開發 API 的公司,也因此我獲得了在 API 方面接受嚴格培訓的機會。我的導師是 Steve Hawley,他是一個喜歡在研究解決各種疑難雜癥的問題上花費大量時間的人,并且他會把這些解決方面整理出來。Steve 并沒有那么多耐心去給新手充當一個保姆,所以他總是喜歡把整理好的方案刻錄成光碟交給我們。在這種方式的督促下,我學的很快。

他的人生觀、他的思想從來不會被一些框框條條所束縛,對于他的那套哲學我稱之為 90-9-0.9:

  • 其中 90% 意味著人們僅需要通過剪切、粘貼 API 文檔中的幾行代碼就可以解決在一般情況下遇到的問題。
  • 接下來的9% 是需要對你的目標進行簡單地配置,甚至有些問題在幾分鐘內就可以簡單地通過文檔查詢或者技術團隊的支持來解決。
  • 最后的0.9%,是指我們需要面對會有人用各種方式濫用你開發的庫,有的時候是因為本身的性能問題,有的時候卻是因為使用者利用了一些難以想象的古怪(但偏偏是可執行的)手段。當然為了保證客戶的需求,犧牲這0.9% 也是完全可取的。
  • 最后,還有0.1% 的人會完全曲解你的產品,這會讓我們的感到非常難受。最好通過市場調查去看看是否需要重視這類用戶,看看他們的是否值得讓自己去擴展庫且添加他們。

對于那些難以滿足的用戶,Atalasoft 做的條形碼產品就是一個很好的例子,當初在產品上投入了很多精力去仔細進行性能調優和預處理,對許多文檔進行掃描后都沒有發現問題。預處理完畢后,我們嘗試了各種類型的條形碼,在最短的時間內給任何可以進行掃描操作的人進行掃描。

使用者可以通過修改一個簡單的枚舉類型的屬性進行配置。但是有些掃描的確很困難,比如掃描一個纏繞在香蕉上的條形碼。對這種情況,可能會讓你無法掃描甚至于更換整個條形碼引擎。但就算如此,也不會有誰拿著這樣的產品去掃描一條寵物店的狗身上剃出來的條形碼吧。如果你是這樣的用戶,建議還是去找其它的產品吧。

當我第一次接觸到這種情況的時候,我感覺這真的是一個很糟糕的設計。整個組件就像一個完全 DIY 的插件系統。Atalasoft 不會為了一些人的審美觀來進行優化,他們只會為了減輕用戶對其產品支持的負擔而進行不斷調優。正如我自己不喜歡把面向對象的思想用來編寫內部庫一樣,單單在開放一個所有級別的用戶都能操作的簡單接口上,我認為沒有比這更好的范式。

在過去的兩年里,我一直在 Bayard Rock 公司負責 API 方面的工作,我們研發的項目主要用于打擊一些洗黑錢活動。這意味著需要做很多小型的實驗項目,偶爾一些中型的實驗項目也會一并在以后會被整合到業內同行的大型平臺上。在大多數情況下,Atalasoft 風格的黑匣子是起不了任何作用的。我們只有一個客戶并且根據他們的需求對我們的外部 API 進行調整。

但是,在一個細粒度級別中,代碼的重用是非常重要的。在這種情況下,最重要的就是構建一個大型數據庫,把許多分類函數快速的組合在一起(通過簡單的組合和不全面的單元測試)而后我們讓然對我們產品的運作信心十足。到目前為止,我們仍在不斷地進行優化實驗并且快速發展我們的組件。

那么,什么是好的 API 設計?就像我們之前所提到了:不要被框框條條所束縛,設計上要按照常規來進行,同時在理解用戶需求的前提下加入我們的設計理念,同時自己的產品在遇到一個會在狗身上剃出條形碼并對其掃描的不靠譜用戶,你應該果斷放棄為他設計產品。

Via Inviting Epiphany

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!