一文讀懂API

API，應用程序編程介面（application programming interface）的縮寫詞，用於從命令行工具到Java、 Ruby on Rails、Web應用等程序。除非你從頭開始編寫每一行代碼，否則你將與外部軟體組件進行交互，每個組件都有自己的API。即使你完全從頭開始寫一些東西，一個精心設計的軟體應用程序也會有內部API來幫助組織代碼，並使組件可重用性更高。

深入研究一下，API是一個與軟體組件交互的規範。例如，如果一輛汽車是一個軟體組件，其API將包括有關加速，制動和打開無線電的能力的信息。它還包括有關如何加速的信息：將腳放在加速踏板上並加油。API定義將「what」和「how」信息彙集在一起，它是汽車本身的抽象。

需要記住的一點是，某些API的名稱通常用於指代交互的規範以及與之交互的實際軟體組件。例如，「Twitter API」這個短語不僅指用於以編程方式與Twitter進行交互的規則集，而且通常被理解為與你交互的內容，例如「我們正在分析從Twitter API獲取的推文「。

讓我們通過Java API和Twitter API作為示例來深入研究。首先，我們將快速了解這兩個API以及它們如何實現「what」和「how」的定義。然後，我們將討論你何時可能會使用API以及如何進行精心設計API。

Java API

Java API是一個「開箱即用」的軟體組件庫，可供安裝Java開發工具包的任何人使用。這些組件執行常見的任務，通常會提高生產力，因為程序員不必每次都從頭開始。軟體中使用的一個基本組件是名為List的東西，正如你所期望的那樣，它可以跟蹤項目列表。Java API定義了你可以對List執行的操作：添加項目，對列表進行排序，確定項目是否在列表中等。它還指定如何執行這些操作。為了對列表進行排序，你需要指定如何排序列表：按字母順序排列，數字遞減排列，最亮至最暗淡的顏色等。

上圖為List的排序方法的OpenJDK API文檔。comparator是確定列表如何排序的參數。

Twitter API

Twitter API是一個基於Web的JSON API，允許開發人員以編程方式與Twitter數據交互。 與包含在Java開發工具包中的Java API不同，Twitter API是一個基於Web的API。必須通過互聯網向Twitter的服務提出請求才能訪問它。

通過基於Web的API（例如Twitter），你的應用程序就像Web瀏覽器一樣發送HTTP請求。 但是，網頁提供的響應，不是為了人類的理解，而是以應用程序可以輕鬆解析的格式返回。 為此目的存在各種格式，Twitter使用稱為JSON的流行且易於使用的格式。

Twitter中的基本元素之一是推文。Twitter API告訴你可以用推文做什麼：搜索推文，創建推文，最喜歡的推文。它還會告訴你如何執行這些操作。要搜索推文，你需要指定搜索條件：要查找的詞條或主題標籤，地理位置，語言等。

上圖是Twitter的Search API文檔。在這裡，你可以找到查詢推文群體所需的所有詳細信息，包括可用搜索運算符以及響應格式。

REST API

Twitter API以及許多其他基於Web的API是REST API的一個例子，也就是說它是一種使用Representational State Transfer（REST）架構風格的API。REST是由Roy Fielding於2000年在他的博士論文中正式介紹的，它是一套用於構建涉及任何類型媒體（文本，視頻等）的分散式系統的架構組件，設計原則和交互。REST的核心是一種構建系統的風格，它允許跨網路靈活地進行通信和顯示信息，同時提供構建通用組件的必要結構。

在REST API中，資源幾乎可以是任何東西，示例包括用戶，推文列表以及搜索推文的當前結果。這些資源中的每一個資源都可通過資源標識符進行定址，對於基於Web的REST API，通常是一個URL，例如https://api.twitter.com/1.1/users/show?screen_name=twitterdev。當應用程序使用標識符請求資源時，API會以該應用程序可以使用的格式（如JPEG圖像，HTML頁面或JSON）將該資源的當前表示形式傳遞給應用程序。

REST最大的區別之一是它涉及向請求應用程序發送數據。雖然這提供了很大的靈活性，但允許應用程序根據數據執行任何操作，這是以犧牲效率為代價的。通過網路發送數據進行處理相對於進行數據駐留的處理相當緩慢，然後發送結果。當然，「高效」方法的問題在於託管數據的系統需要知道應用程序需要提前做什麼。因此，為了構建具有通用可用性和靈活性的API，REST是一條可行的路線。

API作為抽象層

談到軟體，API幾乎無處不在。API與計算機科學中最基本的概念之一是並行的：抽象。抽象只是一種組織系統複雜性的方法，以便以簡單的方式處理複雜的操作。想像一下這種抽象，就像亞馬遜Dash按鈕，你可以用它來訂購亞馬遜的訂書釘。這是他們的樣子：

上圖是亞馬遜Dash按鈕的幾個例子。按下按鈕即可訂購更多清潔劑或紙巾。

你可以從亞馬遜的訂購Dash按鈕開始，並使用智能手機上的應用程序將其與你的Wi-Fi網路，亞馬遜帳戶以及產品（例如你最喜愛的紙巾品牌）相關聯。然後，只要你想訂購更多的紙巾，你只需按下Dash按鈕連接到Internet並發送消息以在你的帳戶上下訂單。幾天後，紙巾將抵達你的家門口。

就像一個API，Dash按鈕是一個非常簡單的界面，隱藏了幕後的各種複雜性。你訂購的產品的ID必須從某個資料庫中檢索。你的收貨地址必須從你的帳戶中提取。必須確定最近的庫存紙巾的履約中心，然後通知從現有庫存中取出物品並將其包裝。最後，包裹必須通過飛機，卡車和貨車以及其他包裹的某種組合來確保所有包裹都能有效抵達目的地。

現在假設作為客戶你必須協調所有這些東西，那你絕對不會訂購紙巾，因為它太複雜、太費時，而且你還有更多的事情要做。幸運的是，整個考驗都是從你身上抽象出來的。計算機系統和人員流程之間存在著長期的相互關聯的鏈條，使得這些紙巾出現在你的家門口，但你只需按下按鈕即可。這就是程序員的API，它們解決了大量的複雜性，並定義了一組可以利用的相對簡單的交互，而不是自己完成所有工作。在任何軟體項目中，你都可能直接使用數十個甚至數百個API，並且每個API都依賴於其他API等。

API設計

API設計是制定API「what」和「how」的過程。與其他任何可以創建的內容一樣，API設計中會考慮到不同程度的思考和關注，從而導致API質量水平不同。精心設計的API具有一致的行為，考慮到其背景，並牢記用戶的需求。

API中的一致行為極大地影響了它的學習速度以及程序員在使用時出錯的可能性。通常，執行類似操作的API應該具有相似的行為，無論其技術差異如何。對於不一致API的示例，我們來看看在Java中將項添加到列表的兩種方法：

即使向列表添加項目的兩種方法執行相同的操作，它們的返回類型（布爾值和空值）也是不同的。使用此API的開發人員現在必須跟蹤哪種方法返回哪種類型，從而使API更難以學習，並且其使用更易於出錯。這也意味著使用這些方法的代碼變得不那麼靈活，因為如果你想要切換添加元素的方式，它必須更改。

考慮到上下文是另一種形式的一致性，儘管它與API的外部因素有關。一個偉大的，非軟體的例子是道路右側交通規則或左側交通規則如何影響不同國家的汽車設計。當駕駛員座椅位於汽車的右側或左側時，汽車設計師會考慮到這一環境因素。

在API設計中，考慮到上下文通常意味著你遵守普遍接受的最佳實踐，並從你的用戶可能熟悉的其他API中獲得靈感。假設你正在構建一個為Java應用程序提供了一種新List的庫，也許是一個專門用於非常大型列表的工具。該List的API應該可能包含一個add方法，其行為與Java List add方法的工作方式相同。這樣，用戶可以輕鬆採用你的庫，因為他們已經知道如何使用它。

了解你的用戶並且牢記他們的需求在API設計中是至關重要的。如果你了解自己的痛點並幫助他們避免這種痛苦，那麼你的API將擁有愉悅的用戶。出於同樣的原因，你可能會選擇違反其他良好API設計規則。如果你正在編寫Web API，那麼今天的事實標準就是使用JSON作為交換格式。但是，如果你的API將為正在檢索大量數據的科學用戶提供服務，那麼JSON將過於冗長而繁瑣地為其提供服務。因此，你可以選擇使用像GRIB這樣的二進位格式，即使它在一般意義上是非常罕見的選擇。

API是軟體設計的重要組成部分，它們存在於軟體堆棧的各個層面。他們提供了一種方式來定義和管理抽象，告訴我們我們可以用軟體組件做什麼以及如何做到這一點。精心設計的API支持高效，流暢和輕鬆的採用和使用，而設計不佳的API在每次使用時都會引起頭痛。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！