API 設計的七大誤區

05-03

對於現在的絕大多數人來說，網站和移動應用已經跟空氣和食物一樣成為生活的必需品。然而在網站和移動系統不斷演化的過程中，前後端分離是系統架構演化的一個重要分水嶺。

隨著系統邏輯和展示層分離的過程中，API 是一個實現這種分散式應用架構的重要機制，從早期單純的 WebService 到 RESTful，API 的設計方法、技術和理念發生了巨大的變化。然而 API 的設計實在是陷阱重重，一不小心就會落入其中，從而連累整個系統。

如果單純地考慮功能的話，大部分服務端開發工程師都可以設計和實現出一個說得過去的 API，但一旦有多個互相關聯的 API，或者當系統壓力達到一定級別時，就會有不少問題出現，甚至導致系統崩潰。

我們可以來看看常見的誤區在什麼地方。

1、API 就是 RESTful API

觀點：RESTful 是現在很流行的一種 API 設計風格，有大量的文章在推薦這種方法，因此我們就需要按照這種風格的要求來設計API，並且要實現全套的設計！

真相：完全不需要！

事實上 RESTful 只是一種設計思想，並不存在具體必須遵守的規則。在不同的應用系統中，API 承擔了不同的各種職責和功能，針對不同的應用場景可以使用相應的規則，適用就好。儘管有一些類似於Richardson成熟度模型這樣的理論，但也都不是必須做到的。雖然最高級別的成熟度是很有用的，但也要求整個系統以特定的方式運作，對於絕大部分的系統來說，低一些級別的成熟度一樣工作良好，並且同時不需要花費太大的代價。

如果實現了比較完整的 RESTful API，那麼會有一些好用的工具和代碼可以利用，但如果自己實現，也未必會有很大的代價。

2、API，不過就是一段 Java 代碼么

觀點：API？不過就是一些 Java 代碼暴露一個 HTTP 地址么，找個會做 Java 的人上就行。

真相：大部分情況下都不是這樣的。

這種說法，和「只要人會說話，就能進行感人的演講」一樣可笑。

（圖樣圖森破）

軟體工具的使用只是一種簡單的技能，但在工具背後的思想是需要經過經驗的積累以及各種周邊知識的共同理解才能做到。

API 的設計與其說是一種技能，不如說是一種藝術，交流的藝術。除了代碼編寫以外，更多的是架構上的設計。API 是整個服務端系統暴露到客戶端的介面，是所有業務邏輯提供給外部的界面，如果對於系統的整體要求和架構不了解，很難設計一個合用的 API 系統。

3、和交互綁定的 API 設計

觀點：API 是給客戶端用的，在現在 App 大行其道的時候，移動端的同事說，我們需要簡化網路交互，所以每個頁面只需要一個 API ——什麼？我要調用8個 API？不行，太慢了，只要一個，把所有的數據都放在一起給我吧，謝謝！

真相：這樣的做法會導致 API 最終完全不可用。

沒錯，從性能的角度上看，確實這樣是比較好的，但是，有沒有想過，如果移動端頁面設計改變了怎麼辦？一旦增加或者減少這個頁面所需要的數據，那麼這個API 立刻就變得沒用了，重新設計一個？算了吧，API 升級的代價太高了，於是越來越多的重複 API 就出現了。

前後端分離的理念在於把業務邏輯和展示分離，API 作為業務邏輯的體現，以業務邏輯作為設計原則，比靠攏易變的展示層要準確和靠譜得多。從這個角度上說，引入一個中間層來適應展示的變化會更加適合。

4、我的 API 是我的，你的 API 是你的，不互通的 API 設計

觀點：系統 A 提供了一組 API，系統 B，恩，另外一個系統，所以我們需要另外一組 API，但是，不好意思，我不知道 A 是怎麼做的，並且我也不關心。

真相：這是一種系統分裂的徵兆，是系統業務邏輯混亂的表現。

如果把應用程序介面比做用戶介面的話，這樣的說法就很奇怪了。作為一個公司下的不同系統，長得完全不一樣，互相之間沒有任何關聯性，這樣用戶在使用的時候會很彆扭。如果把系統當成一個人，這樣的設計就和這個人有兩張臉一樣奇怪。作為系統的架構師，要為全公司設定一個一致的API規範，程序員們對接入各個系統可以有明確的預期，並且非常有助於在系統和客戶端之間共享代碼，簡化開發和維護的成本。

5、API = 資料庫

觀點：API 設計？簡單，資料庫的操作映射一下好了。創建一個對象，修改一個對象，刪除一個對象，贊！API 設計的生活是如此簡單。

真相：等一下，作為API的使用者，客戶端應用為什麼需要知道資料庫？難道不應該是業務驅動的嗎？

很多 API 確實就是這樣設計的，但如果只是單純地按照資料庫的結構進行設計，那麼只能說是一個資料庫的訪問層而已，是SQL 語句的 HTTP 化…… 但 API應當反映的是業務內在邏輯，包括業務對象、流程和業務數據，在基於資料庫的基礎上，通過伺服器端的業務層處理後才是 API 應當的結果。

6、我的自留地 API，API 不開放標準

觀點：我沒打算開放 API 給別人用，所以也不需要遵守什麼標準。

真相：標準意味著通用，有更多的簡化。

話是不錯，但標準的好處在於設定交流雙方的一個基礎，作為伺服器對外的交流介面，API 始終是設計得給人用的，不僅僅是公司內部，也有可能是外部；不僅僅是現在，也有可能是未來的人在使用。和代碼規範一樣，符合良好規範的 API 能夠極大地改善可讀性、維護性，即使不開放給外部，內部交流也會獲益良多。

7、我不說，你就不知道，API 的安全性

觀點：這個 API 又沒有公開，所以不需要加密的。

真相：在這個互聯網上是沒有秘密的，所以你不讓人知道，不代表別人不會知道。

關於安全，這個是 API 設計中非常重要的一個需求，但很多 API 的設計師並不重視這個。最常見的借口就是這個，我不告訴別人，誰也不知道。但事實上，API 作為交流的工具，即使服務端不容易被窺視，但大量的客戶端幾乎是不設防的。破解一個客戶端系統並不是一個多麼困難的事情，因此了解這個 API 的調用也不是太複雜的事情。

此外，在網路上的傳輸也是不安全的，中間人截獲信息的案例導致無數的系統被攻破。按照業界的推薦方法來設計 API 的安全傳輸功能，儘管開發的代價會略大一些，但遠比自己自以為完美的設計安全得多。

寫在最後

隨著越來越多的人在使用互聯網，用戶界面（UX）設計的影響也越來越大，所有人都開始注重用戶界面設計的好壞，然而 API 是業務邏輯的用戶界面，是針對程序員的界面，避免這些誤區陷阱可以讓這些界面更加友好，在業務邏輯和展示層都能運作得更好。

本文作者：徐翎 Andrew（點融黑幫），任職點融網客戶端開發總監，組建了移動和網站的開發團隊，開發了點融網各款客戶端軟體。曾就職於微軟等公司，參與過包括Hotmail 和Windows 在內的大型跨國際軟體開發項目的研發。

本文由@點融黑幫（ID：DianrongMafia）原創發佈於知乎，未經許可，禁止轉載。

http://weixin.qq.com/r/B0UqMmXE_ziErSFR9xAV (二維碼自動識別)