[[242112]]

【51CTO.com快譯】早在我開始學習前端Web開發(fā)，頭一回遇到“API”時，這個術(shù)語聽起來像是某種精釀啤酒。后來我有了切身體會：如果你去酒吧要一杯API，酒保會拋出“404：資源未找到”的錯誤。是我自己讓人笑話了。

API是我們一直在用的東西。盡管API無處不在，但許多人、甚至技術(shù)人員對于它們是什么及工作方式有著很模糊的理解。說真的，請你的同事馬上解釋一下API。如果對方立馬說“API指應用編程接口。它是讓軟件應用程序彼此通信的接口......”我會請這個人喝啤酒。大多數(shù)人真的無法闡明API。

讓我們改變這種情況。

“A”表示應用。

該術(shù)語的第一個部分高度依賴上下文。視具體的使用場景而定，“應用”實際上可以指很多東西：整個服務器、整個應用程序本身及其所需的數(shù)據(jù)或只是應用程序的一小部分。

不妨看看這些上下文：服務器、整個應用程序和應用程序的一小部分。我們先設想Web是聯(lián)網(wǎng)服務器組成的龐大全球網(wǎng)絡?；ヂ?lián)網(wǎng)上的每一頁都存儲在這其中一臺遠程服務器上的某個地方，即位于遠處的計算機，經(jīng)過優(yōu)化以處理向你的瀏覽器提供這個特定網(wǎng)站的請求。

因此，如果你在瀏覽器欄中輸入www.github.com，Chrome、Firefox或Safari等瀏覽器向GitHub的服務器發(fā)送請求，服務器會禮貌地發(fā)回在本地計算機上顯示頁面及內(nèi)容所需要的全部代碼。瀏覽器收到此響應后，它會解釋代碼并顯示頁面。

服務器作為API：在你的瀏覽器（又叫客戶端）看來，GitHub的服務器就是API。這意味著每次你訪問Web上的頁面時，都與某臺遠程服務器的API進行交互。此處的API與遠程服務器不一樣。相反，它是接收請求并發(fā)送響應的服務器的一部分。

整個應用程序作為API：初始調(diào)用時，GitHub服務器發(fā)送整個Web應用程序：表示結(jié)構(gòu)（網(wǎng)站布局及外觀）以及網(wǎng)站的所有內(nèi)容。表示這部分基本上固定不變，作為HTML代碼發(fā)送，由瀏覽器顯示。內(nèi)容（網(wǎng)站中包含的動態(tài)信息）作為數(shù)據(jù)發(fā)送，常常采用JSON格式，然后在頁面上的適當位置加以顯示。

所以如果我們看一下典型的GitHub頁面，表示部分（比如頂部的導航欄、左邊的用戶照片和簡介、中間固定的存儲倉庫）幾乎保持一樣。但那些綠色小方形表示每日GitHub活動量的方框呢？這會根據(jù)用戶的貢獻而變化。我們將項目工作推送到GitHub，然后檢查以確保它已添加到簡介頁面上時，API告訴瀏覽器將今天的方形標成綠色、它到底應該用什么色度。但是，其他的一切保持不變。

不同類型的API讓我們的瀏覽器可以調(diào)用特定類型的信息，只更新相關(guān)的數(shù)據(jù)，無需重新加載沒有變的其他所有內(nèi)容。

應用程序的一部分作為API：構(gòu)建Web應用程序時，用之前就由組件來構(gòu)建快得多、容易得多（并且常常更可靠）。設想一下，很可能有一個庫、預制平臺或XaaS來提供。

但是這些組件如何相互通信，以便作為一個統(tǒng)一的應用程序來執(zhí)行？

“P”表示協(xié)議，“I”表示接口

API的應用端可能大不一樣，但無論我們談論什么樣的上下文，API的最終任務仍然一樣：溝通和協(xié)調(diào)。

API中的“P”即協(xié)議指確定彼此約定的方法，以便其他軟件與特定的API聯(lián)系，請求/接收來自它的相關(guān)信息。

接口指API的中間方面，充當讓兩個應用程序能夠相互聯(lián)系的實際功能。

因此從根本上說，API好比是兩個軟件之間的一種協(xié)議或契約，這個“粘合層”讓它們能夠?qū)?、協(xié)同運行。實際上，API說“如果你給我這個指令，我會執(zhí)行此操作/返回此信息。”

打個比喻，API好比微釀啤酒廠的啤酒水龍頭。每個水龍頭對應某一類啤酒，所以當你按下標有“Porter”的水龍頭把手時，就知道你的杯里會灌滿濃郁的麥香味啤酒，按下“Pilsner”會出來清爽的黃色啤酒。同樣道理，請求API輸出的客戶端知道按下哪個數(shù)據(jù)“水龍頭”以便獲得所需的輸出。比如說，Porter預計從porter水龍頭出來，而不是別的水龍頭。同時，用戶甚至不必知道或關(guān)心水龍頭內(nèi)部的情況?？梢灾匦屡帕嘘犖榛騼?yōu)化產(chǎn)品（你提供的啤酒或應用程序），而不影響用戶，因為接口仍然一樣。

API不僅僅推送數(shù)據(jù)，還接受數(shù)據(jù)。這里啤酒比喻不恰當，因為啤酒是單向流動。因此，我們用另外的比喻來說明數(shù)據(jù)如何進入API。設想一下小孩子玩的形狀分類器玩具。圓形、星形和三角形的拼塊通過適當形狀的開口插入；星形拼塊只能通過星形孔插入。在API中，數(shù)據(jù)以一種定義的形式（比如圓形或三角形）來提供，只能通過相應的開口穿過接口。API要求是某種格式，拒絕不適合的數(shù)據(jù)。別試圖將三角形數(shù)據(jù)放入到方孔。因此，客戶端被迫按照API構(gòu)建器的規(guī)范（即協(xié)議）來組織輸入，該規(guī)范為事務設定了預期要求。

無論我們用什么比喻來解釋API，API都好比是兩個軟件之間的協(xié)議或契約，說“如果你給我這個指令，并采用這種格式，我就會執(zhí)行這個指定的動作或返回此信息。”

API作為產(chǎn)品

除了作為瀏覽器、服務器、軟件和數(shù)據(jù)庫之間交換信息的載體外，API還可以打包成產(chǎn)品來銷售。比如說，Weather Underground售賣訪問其天氣數(shù)據(jù)API的服務。這是一組專用的URL，返回純數(shù)據(jù)響應（這里是最新的天氣預報），以便用來在你自己的應用程序中豐富數(shù)據(jù)。你不是得到Weather Underground在其自己的應用程序或網(wǎng)站上所用的表示結(jié)構(gòu)，你構(gòu)建自己的圖形用戶界面。

話雖如此，你絕對可以用瀏覽器向API發(fā)出請求，查看返回的數(shù)據(jù)，無論用不用GUI。由于請求數(shù)據(jù)的實際HTTP傳輸以文本形式發(fā)生，你的瀏覽器通常能夠顯示響應。比如說，你可以直接用瀏覽器訪問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頁面時，它調(diào)用GitHub API，以獲取顯示頁面的表示代碼（HTML/CSS），并調(diào)用另一個GitHub API以獲取對我來說獨特的數(shù)據(jù)。還有針對其他API的另外幾個調(diào)用，以獲取頁面其他區(qū)域中的內(nèi)容。瀏覽器收到所有這些調(diào)用后，知道將數(shù)據(jù)插入到頁面，生成最終的、統(tǒng)一的表示。

組合起來

基本上來說，任何一款可與其運行時環(huán)境明確分開來的軟件都能成為API中的“A”。它本身也可能有某種API。比如說，假設你在代碼中使用第三方庫。一旦該庫合并到你的代碼中，就成為整個應用程序的永久部分。然而作為一個獨特的軟件，該庫使用API（無需擔心，API預先打包），以便與你的其余代碼進行交互。

所以API可以是服務器、應用程序，甚至買賣的產(chǎn)品。這就是為什么API很難解釋，即使對于每天接觸API的人來說也是如此。

也許定義API本質(zhì)的最恰當?shù)姆椒ㄊ鞘褂脴犯叻e木。積木提供了一種簡單且結(jié)構(gòu)化的方式，讓所有積木都以同樣的方式拼接起來。同時，積木可能的組合無窮無盡。與之相仿，軟件可以使用API來連接我們尋找的信息以及查看信息的接口，創(chuàng)建獨特的服務組合，而這些服務共同形成一個應用程序。

樂高積木確實有助于開發(fā)人員了解API的價值。使用API，開發(fā)人員沒必要每次編寫新程序時從頭開始。他們不再需要構(gòu)建一個試圖做所有任務的核心應用程序。相反，他們可以使用已經(jīng)創(chuàng)建的更好地完成任務的組件，將某些責任分包出去。所以API是軟件開發(fā)界的樂高積木：這種標準化的工具便于軟件與其他軟件聯(lián)系，因而加快構(gòu)建和部署，還能為每個人縮短加載時間。

原文標題：Tutorial: APIs Explained, Using Beer and Legos，作者：Michelle Gienow

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】