API難解釋？這次用啤酒和積木來破局
譯文【51CTO.com快譯】早在我開始學習前端Web開發，頭一回遇到“API”時，這個術語聽起來像是某種精釀啤酒。后來我有了切身體會：如果你去酒吧要一杯API，酒保會拋出“404：資源未找到”的錯誤。是我自己讓人笑話了。
API是我們一直在用的東西。盡管API無處不在，但許多人、甚至技術人員對于它們是什么及工作方式有著很模糊的理解。說真的，請你的同事馬上解釋一下API。如果對方立馬說“API指應用編程接口。它是讓軟件應用程序彼此通信的接口......”我會請這個人喝啤酒。大多數人真的無法闡明API。
讓我們改變這種情況。
“A”表示應用。
該術語的第一個部分高度依賴上下文。視具體的使用場景而定，“應用”實際上可以指很多東西：整個服務器、整個應用程序本身及其所需的數據或只是應用程序的一小部分。
不妨看看這些上下文：服務器、整個應用程序和應用程序的一小部分。我們先設想Web是聯網服務器組成的龐大全球網絡。互聯網上的每一頁都存儲在這其中一臺遠程服務器上的某個地方，即位于遠處的計算機，經過優化以處理向你的瀏覽器提供這個特定網站的請求。
因此，如果你在瀏覽器欄中輸入www.github.com，Chrome、Firefox或Safari等瀏覽器向GitHub的服務器發送請求，服務器會禮貌地發回在本地計算機上顯示頁面及內容所需要的全部代碼。瀏覽器收到此響應后，它會解釋代碼并顯示頁面。
服務器作為API：在你的瀏覽器（又叫客戶端）看來，GitHub的服務器就是API。這意味著每次你訪問Web上的頁面時，都與某臺遠程服務器的API進行交互。此處的API與遠程服務器不一樣。相反，它是接收請求并發送響應的服務器的一部分。
整個應用程序作為API：初始調用時，GitHub服務器發送整個Web應用程序：表示結構（網站布局及外觀）以及網站的所有內容。表示這部分基本上固定不變，作為HTML代碼發送，由瀏覽器顯示。內容（網站中包含的動態信息）作為數據發送，常常采用JSON格式，然后在頁面上的適當位置加以顯示。
所以如果我們看一下典型的GitHub頁面，表示部分（比如頂部的導航欄、左邊的用戶照片和簡介、中間固定的存儲倉庫）幾乎保持一樣。但那些綠色小方形表示每日GitHub活動量的方框呢？這會根據用戶的貢獻而變化。我們將項目工作推送到GitHub，然后檢查以確保它已添加到簡介頁面上時，API告訴瀏覽器將今天的方形標成綠色、它到底應該用什么色度。但是，其他的一切保持不變。
不同類型的API讓我們的瀏覽器可以調用特定類型的信息，只更新相關的數據，無需重新加載沒有變的其他所有內容。
應用程序的一部分作為API：構建Web應用程序時，用之前就由組件來構建快得多、容易得多（并且常常更可靠）。設想一下，很可能有一個庫、預制平臺或XaaS來提供。
但是這些組件如何相互通信，以便作為一個統一的應用程序來執行？
“P”表示協議，“I”表示接口
API的應用端可能大不一樣，但無論我們談論什么樣的上下文，API的最終任務仍然一樣：溝通和協調。
API中的“P”即協議指確定彼此約定的方法，以便其他軟件與特定的API聯系，請求/接收來自它的相關信息。
接口指API的中間方面，充當讓兩個應用程序能夠相互聯系的實際功能。
因此從根本上說，API好比是兩個軟件之間的一種協議或契約，這個“粘合層”讓它們能夠對接、協同運行。實際上，API說“如果你給我這個指令，我會執行此操作/返回此信息。”
打個比喻，API好比微釀啤酒廠的啤酒水龍頭。每個水龍頭對應某一類啤酒，所以當你按下標有“Porter”的水龍頭把手時，就知道你的杯里會灌滿濃郁的麥香味啤酒，按下“Pilsner”會出來清爽的黃色啤酒。同樣道理，請求API輸出的客戶端知道按下哪個數據“水龍頭”以便獲得所需的輸出。比如說，Porter預計從porter水龍頭出來，而不是別的水龍頭。同時，用戶甚至不必知道或關心水龍頭內部的情況。可以重新排列隊伍或優化產品（你提供的啤酒或應用程序），而不影響用戶，因為接口仍然一樣。
API不僅僅推送數據，還接受數據。這里啤酒比喻不恰當，因為啤酒是單向流動。因此，我們用另外的比喻來說明數據如何進入API。設想一下小孩子玩的形狀分類器玩具。圓形、星形和三角形的拼塊通過適當形狀的開口插入；星形拼塊只能通過星形孔插入。在API中，數據以一種定義的形式（比如圓形或三角形）來提供，只能通過相應的開口穿過接口。API要求是某種格式，拒絕不適合的數據。別試圖將三角形數據放入到方孔。因此，客戶端被迫按照API構建器的規范（即協議）來組織輸入，該規范為事務設定了預期要求。
無論我們用什么比喻來解釋API，API都好比是兩個軟件之間的協議或契約，說“如果你給我這個指令，并采用這種格式，我就會執行這個指定的動作或返回此信息。”
API作為產品
除了作為瀏覽器、服務器、軟件和數據庫之間交換信息的載體外，API還可以打包成產品來銷售。比如說，Weather Underground售賣訪問其天氣數據API的服務。這是一組專用的URL，返回純數據響應（這里是最新的天氣預報），以便用來在你自己的應用程序中豐富數據。你不是得到Weather Underground在其自己的應用程序或網站上所用的表示結構，你構建自己的圖形用戶界面。
話雖如此，你絕對可以用瀏覽器向API發出請求，查看返回的數據，無論用不用GUI。由于請求數據的實際HTTP傳輸以文本形式發生，你的瀏覽器通常能夠顯示響應。比如說，你可以直接用瀏覽器訪問GitHub的API，甚至無需訪問令牌。以下是你在瀏覽器中訪問GitHub用戶的API路由時獲得的JSON響應，不妨看看我的：
- {
- "login": "mgienow",
- "id": 19556217,
- "node_id": "MDQ6VXNlcjE5NTU2MjE3",
- "avatar_url": "https://avatars2.githubusercontent.com/u/19556217?v=4",
- "gravatar_id": "",
- "url": "https://api.github.com/users/mgienow",
- "html_url": "https://github.com/mgienow",
- "followers_url": "https://api.github.com/users/mgienow/followers",
- "following_url": "https://api.github.com/users/mgienow/following{/other_user}",
- "gists_url": "https://api.github.com/users/mgienow/gists{/gist_id}",
- "starred_url": "https://api.github.com/users/mgienow/starred{/owner}{/repo}",
- "subscriptions_url": "https://api.github.com/users/mgienow/subscriptions",
- "organizations_url": "https://api.github.com/users/mgienow/orgs",
- "repos_url": "https://api.github.com/users/mgienow/repos",
- "events_url": "https://api.github.com/users/mgienow/events{/privacy}",
- "received_events_url": "https://api.github.com/users/mgienow/received_events",
- "type": "User",
- "site_admin": false,
- "name": "Michelle Gienow",
- "company": null,
- "blog": "",
- "location": "Baltimore, MD",
- "email": null,
- "hireable": true,
- "bio": "Front-end web developer & recovering journalist - I write web dev/JS/Node/Python @TheNewStack",
- "public_gists": 1,
- "followers": 11,
- "following": 2,
- "created_at": "2016-05-24T16:33:09Z",
- "updated_at": "2018-01-27T03:26:14Z"
- }
所以你訪問我的GitHub頁面時，它調用GitHub API，以獲取顯示頁面的表示代碼（HTML/CSS），并調用另一個GitHub API以獲取對我來說獨特的數據。還有針對其他API的另外幾個調用，以獲取頁面其他區域中的內容。瀏覽器收到所有這些調用后，知道將數據插入到頁面，生成最終的、統一的表示。
組合起來
基本上來說，任何一款可與其運行時環境明確分開來的軟件都能成為API中的“A”。它本身也可能有某種API。比如說，假設你在代碼中使用第三方庫。一旦該庫合并到你的代碼中，就成為整個應用程序的永久部分。然而作為一個獨特的軟件，該庫使用API（無需擔心，API預先打包），以便與你的其余代碼進行交互。
所以API可以是服務器、應用程序，甚至買賣的產品。這就是為什么API很難解釋，即使對于每天接觸API的人來說也是如此。
也許定義API本質的最恰當的方法是使用樂高積木。積木提供了一種簡單且結構化的方式，讓所有積木都以同樣的方式拼接起來。同時，積木可能的組合無窮無盡。與之相仿，軟件可以使用API來連接我們尋找的信息以及查看信息的接口，創建獨特的服務組合，而這些服務共同形成一個應用程序。
樂高積木確實有助于開發人員了解API的價值。使用API，開發人員沒必要每次編寫新程序時從頭開始。他們不再需要構建一個試圖做所有任務的核心應用程序。相反，他們可以使用已經創建的更好地完成任務的組件，將某些責任分包出去。所以API是軟件開發界的樂高積木：這種標準化的工具便于軟件與其他軟件聯系，因而加快構建和部署，還能為每個人縮短加載時間。
原文標題：Tutorial: APIs Explained, Using Beer and Legos，作者：Michelle Gienow
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
