對于現(xiàn)在的絕大多數(shù)人來說，網(wǎng)站和移動應(yīng)用已經(jīng)跟空氣和食物一樣成為生活的必需品。然而在網(wǎng)站和移動系統(tǒng)不斷演化的過程中，前后端分離是系統(tǒng)架構(gòu)演化的一個重要分水嶺。

隨著系統(tǒng)邏輯和展示層分離的過程中，API 是一個實現(xiàn)這種分布式應(yīng)用架構(gòu)的重要機制，從早期單純的 WebService 到 RESTful，API 的設(shè)計方法、技術(shù)和理念發(fā)生了巨大的變化。然而 API 的設(shè)計實在是陷阱重重，一不小心就會落入其中，從而連累整個系統(tǒng)。

如果單純地考慮功能的話，大部分服務(wù)端開發(fā)工程師都可以設(shè)計和實現(xiàn)出一個說得過去的 API，但一旦有多個互相關(guān)聯(lián)的 API，或者當(dāng)系統(tǒng)壓力達到一定級別時，就會有不少問題出現(xiàn)，甚至導(dǎo)致系統(tǒng)崩潰。

我們可以來看看常見的誤區(qū)在什么地方。

API 就是 RESTful API

觀點：RESTful 是現(xiàn)在很流行的一種 API 設(shè)計風(fēng)格，有大量的文章在推薦這種方法，因此我們就需要按照這種風(fēng)格的要求來設(shè)計API，并且要實現(xiàn)全套的設(shè)計

真相：完全不需要！

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

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

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

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

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

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

（圖樣圖森破）

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

API 的設(shè)計與其說是一種技能，不如說是一種藝術(shù)，交流的藝術(shù)。除了代碼編寫以外，更多的是架構(gòu)上的設(shè)計。API 是整個服務(wù)端系統(tǒng)暴露到客戶端的接口，是所有業(yè)務(wù)邏輯提供給外部的界面，如果對于系統(tǒng)的整體要求和架構(gòu)不了解，很難設(shè)計一個合用的 API 系統(tǒng)。

和交互綁定的 API 設(shè)計

觀點：API 是給客戶端用的，在現(xiàn)在 App 大行其道的時候，移動端的同事說，我們需要簡化網(wǎng)絡(luò)交互，所以每個頁面只需要一個 API ——什么？我要調(diào)用8個 API？不行，太慢了，只要一個，把所有的數(shù)據(jù)都放在一起給我吧，謝謝！

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

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

前后端分離的理念在于把業(yè)務(wù)邏輯和展示分離，API 作為業(yè)務(wù)邏輯的體現(xiàn)，以業(yè)務(wù)邏輯作為設(shè)計原則，比靠攏易變的展示層要準(zhǔn)確和靠譜得多。從這個角度上說，引入一個中間層來適應(yīng)展示的變化會更加適合。

我的 API 是我的，你的 API 是你的，不互通的 API 設(shè)計

觀點：系統(tǒng) A 提供了一組 API，系統(tǒng) B，恩，另外一個系統(tǒng)，所以我們需要另外一組 API，但是，不好意思，我不知道 A 是怎么做的，并且我也不關(guān)心。

真相：這是一種系統(tǒng)分裂的征兆，是系統(tǒng)業(yè)務(wù)邏輯混亂的表現(xiàn)。

如果把應(yīng)用程序接口比做用戶接口的話，這樣的說法就很奇怪了。作為一個公司下的不同系統(tǒng)，長得完全不一樣，互相之間沒有任何關(guān)聯(lián)性，這樣用戶在使用的時候會很別扭。如果把系統(tǒng)當(dāng)成一個人，這樣的設(shè)計就和這個人有兩張臉一樣奇怪。作為系統(tǒng)的架構(gòu)師，要為全公司設(shè)定一個一致的API規(guī)范，程序員們對接入各個系統(tǒng)可以有明確的預(yù)期，并且非常有助于在系統(tǒng)和客戶端之間共享代碼，簡化開發(fā)和維護的成本。

API = 數(shù)據(jù)庫

觀點：API 設(shè)計？簡單，數(shù)據(jù)庫的操作映射一下好了。創(chuàng)建一個對象，修改一個對象，刪除一個對象，贊！API 設(shè)計的生活是如此簡單。

真相：等一下，作為API的使用者，客戶端應(yīng)用為什么需要知道數(shù)據(jù)庫？難道不應(yīng)該是業(yè)務(wù)驅(qū)動的嗎？

很多 API 確實就是這樣設(shè)計的，但如果只是單純地按照數(shù)據(jù)庫的結(jié)構(gòu)進行設(shè)計，那么只能說是一個數(shù)據(jù)庫的訪問層而已，是SQL 語句的 HTTP 化…… 但 API應(yīng)當(dāng)反映的是業(yè)務(wù)內(nèi)在邏輯，包括業(yè)務(wù)對象、流程和業(yè)務(wù)數(shù)據(jù)，在基于數(shù)據(jù)庫的基礎(chǔ)上，通過服務(wù)器端的業(yè)務(wù)層處理后才是 API 應(yīng)當(dāng)?shù)慕Y(jié)果。

我的自留地 API，API 不開放標(biāo)準(zhǔn)

觀點：我沒打算開放 API 給別人用，所以也不需要遵守什么標(biāo)準(zhǔn)。

真相：標(biāo)準(zhǔn)意味著通用，有更多的簡化。

話是不錯，但標(biāo)準(zhǔn)的好處在于設(shè)定交流雙方的一個基礎(chǔ)，作為服務(wù)器對外的交流接口，API 始終是設(shè)計得給人用的，不僅僅是公司內(nèi)部，也有可能是外部；不僅僅是現(xiàn)在，也有可能是未來的人在使用。和代碼規(guī)范一樣，符合良好規(guī)范的 API 能夠極大地改善可讀性、維護性，即使不開放給外部，內(nèi)部交流也會獲益良多。

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

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

真相：在這個互聯(lián)網(wǎng)上是沒有秘密的，所以你不讓人知道，不代表別人不會知道。

關(guān)于安全，這個是 API 設(shè)計中非常重要的一個需求，但很多 API 的設(shè)計師并不重視這個。最常見的借口就是這個，我不告訴別人，誰也不知道。但事實上，API 作為交流的工具，即使服務(wù)端不容易被窺視，但大量的客戶端幾乎是不設(shè)防的。破解一個客戶端系統(tǒng)并不是一個多么困難的事情，因此了解這個 API 的調(diào)用也不是太復(fù)雜的事情。

此外，在網(wǎng)絡(luò)上的傳輸也是不安全的，中間人截獲信息的案例導(dǎo)致無數(shù)的系統(tǒng)被攻破。按照業(yè)界的推薦方法來設(shè)計 API 的安全傳輸功能，盡管開發(fā)的代價會略大一些，但遠(yuǎn)比自己自以為完美的設(shè)計安全得多。

寫在最后

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

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

End.

轉(zhuǎn)載請注明來自36大數(shù)據(jù)（36dsj.com)：36大數(shù)據(jù) » API 設(shè)計的七大誤區(qū)