建站
咨詢
售后
建站咨詢
新聞中心
早在我開始學(xué)習(xí)前端Web開發(fā)，頭一回遇到“API”時，這個術(shù)語聽起來像是某種精釀啤酒。后來我有了切身體會：如果你去酒吧要一杯API，酒保會拋出“404：資源未找到”的錯誤。是我自己讓人笑話了。
金沙網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián)公司,金沙網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為金沙上1000家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請找那個售后服務(wù)好的金沙做網(wǎng)站的公司定做！
API是我們一直在用的東西。盡管API無處不在，但許多人、甚至技術(shù)人員對于它們是什么及工作方式有著很模糊的理解。說真的，請你的同事馬上解釋一下API。如果對方立馬說“API指應(yīng)用編程接口。它是讓軟件應(yīng)用程序彼此通信的接口......”我會請這個人喝啤酒。大多數(shù)人真的無法闡明API。
讓我們改變這種情況。
“A”表示應(yīng)用。
該術(shù)語的第一個部分高度依賴上下文。視具體的使用場景而定，“應(yīng)用”實際上可以指很多東西：整個服務(wù)器、整個應(yīng)用程序本身及其所需的數(shù)據(jù)或只是應(yīng)用程序的一小部分。
不妨看看這些上下文：服務(wù)器、整個應(yīng)用程序和應(yīng)用程序的一小部分。我們先設(shè)想Web是聯(lián)網(wǎng)服務(wù)器組成的龐大全球網(wǎng)絡(luò)?；ヂ?lián)網(wǎng)上的每一頁都存儲在這其中一臺遠程服務(wù)器上的某個地方，即位于遠處的計算機，經(jīng)過優(yōu)化以處理向你的瀏覽器提供這個特定網(wǎng)站的請求。
因此，如果你在瀏覽器欄中輸入www.github.com，Chrome、Firefox或Safari等瀏覽器向GitHub的服務(wù)器發(fā)送請求，服務(wù)器會禮貌地發(fā)回在本地計算機上顯示頁面及內(nèi)容所需要的全部代碼。瀏覽器收到此響應(yīng)后，它會解釋代碼并顯示頁面。
服務(wù)器作為API：在你的瀏覽器（又叫客戶端）看來，GitHub的服務(wù)器就是API。這意味著每次你訪問Web上的頁面時，都與某臺遠程服務(wù)器的API進行交互。此處的API與遠程服務(wù)器不一樣。相反，它是接收請求并發(fā)送響應(yīng)的服務(wù)器的一部分。
整個應(yīng)用程序作為API：初始調(diào)用時，GitHub服務(wù)器發(fā)送整個Web應(yīng)用程序：表示結(jié)構(gòu)（網(wǎng)站布局及外觀）以及網(wǎng)站的所有內(nèi)容。表示這部分基本上固定不變，作為HTML代碼發(fā)送，由瀏覽器顯示。內(nèi)容（網(wǎng)站中包含的動態(tài)信息）作為數(shù)據(jù)發(fā)送，常常采用JSON格式，然后在頁面上的適當(dāng)位置加以顯示。
所以如果我們看一下典型的GitHub頁面，表示部分（比如頂部的導(dǎo)航欄、左邊的用戶照片和簡介、中間固定的存儲倉庫）幾乎保持一樣。但那些綠色小方形表示每日GitHub活動量的方框呢？這會根據(jù)用戶的貢獻而變化。我們將項目工作推送到GitHub，然后檢查以確保它已添加到簡介頁面上時，API告訴瀏覽器將今天的方形標(biāo)成綠色、它到底應(yīng)該用什么色度。但是，其他的一切保持不變。
不同類型的API讓我們的瀏覽器可以調(diào)用特定類型的信息，只更新相關(guān)的數(shù)據(jù)，無需重新加載沒有變的其他所有內(nèi)容。
應(yīng)用程序的一部分作為API：構(gòu)建Web應(yīng)用程序時，用之前就由組件來構(gòu)建快得多、容易得多（并且常常更可靠）。設(shè)想一下，很可能有一個庫、預(yù)制平臺或XaaS來提供。
但是這些組件如何相互通信，以便作為一個統(tǒng)一的應(yīng)用程序來執(zhí)行？
“P”表示協(xié)議，“I”表示接口
API的應(yīng)用端可能大不一樣，但無論我們談?wù)撌裁礃拥纳舷挛?，API的最終任務(wù)仍然一樣：溝通和協(xié)調(diào)。
API中的“P”即協(xié)議指確定彼此約定的方法，以便其他軟件與特定的API聯(lián)系，請求/接收來自它的相關(guān)信息。
接口指API的中間方面，充當(dāng)讓兩個應(yīng)用程序能夠相互聯(lián)系的實際功能。
因此從根本上說，API好比是兩個軟件之間的一種協(xié)議或契約，這個“粘合層”讓它們能夠?qū)印f(xié)同運行。實際上，API說“如果你給我這個指令，我會執(zhí)行此操作/返回此信息。”
打個比喻，API好比微釀啤酒廠的啤酒水龍頭。每個水龍頭對應(yīng)某一類啤酒，所以當(dāng)你按下標(biāo)有“Porter”的水龍頭把手時，就知道你的杯里會灌滿濃郁的麥香味啤酒，按下“Pilsner”會出來清爽的黃色啤酒。同樣道理，請求API輸出的客戶端知道按下哪個數(shù)據(jù)“水龍頭”以便獲得所需的輸出。比如說，Porter預(yù)計從porter水龍頭出來，而不是別的水龍頭。同時，用戶甚至不必知道或關(guān)心水龍頭內(nèi)部的情況?？梢灾匦屡帕嘘犖榛騼?yōu)化產(chǎn)品（你提供的啤酒或應(yīng)用程序），而不影響用戶，因為接口仍然一樣。
API不僅僅推送數(shù)據(jù)，還接受數(shù)據(jù)。這里啤酒比喻不恰當(dāng)，因為啤酒是單向流動。因此，我們用另外的比喻來說明數(shù)據(jù)如何進入API。設(shè)想一下小孩子玩的形狀分類器玩具。圓形、星形和三角形的拼塊通過適當(dāng)形狀的開口插入；星形拼塊只能通過星形孔插入。在API中，數(shù)據(jù)以一種定義的形式（比如圓形或三角形）來提供，只能通過相應(yīng)的開口穿過接口。API要求是某種格式，拒絕不適合的數(shù)據(jù)。別試圖將三角形數(shù)據(jù)放入到方孔。因此，客戶端被迫按照API構(gòu)建器的規(guī)范（即協(xié)議）來組織輸入，該規(guī)范為事務(wù)設(shè)定了預(yù)期要求。
無論我們用什么比喻來解釋API，API都好比是兩個軟件之間的協(xié)議或契約，說“如果你給我這個指令，并采用這種格式，我就會執(zhí)行這個指定的動作或返回此信息?！?/p>
API作為產(chǎn)品
除了作為瀏覽器、服務(wù)器、軟件和數(shù)據(jù)庫之間交換信息的載體外，API還可以打包成產(chǎn)品來銷售。比如說，Weather Underground售賣訪問其天氣數(shù)據(jù)API的服務(wù)。這是一組專用的URL，返回純數(shù)據(jù)響應(yīng)（這里是最新的天氣預(yù)報），以便用來在你自己的應(yīng)用程序中豐富數(shù)據(jù)。你不是得到Weather Underground在其自己的應(yīng)用程序或網(wǎng)站上所用的表示結(jié)構(gòu)，你構(gòu)建自己的圖形用戶界面。
話雖如此，你絕對可以用瀏覽器向API發(fā)出請求，查看返回的數(shù)據(jù)，無論用不用GUI。由于請求數(shù)據(jù)的實際HTTP傳輸以文本形式發(fā)生，你的瀏覽器通常能夠顯示響應(yīng)。比如說，你可以直接用瀏覽器訪問GitHub的API，甚至無需訪問令牌。以下是你在瀏覽器中訪問GitHub用戶的API路由時獲得的JSON響應(yīng)，不妨看看我的：
- {
- "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。比如說，假設(shè)你在代碼中使用第三方庫。一旦該庫合并到你的代碼中，就成為整個應(yīng)用程序的永久部分。然而作為一個獨特的軟件，該庫使用API（無需擔(dān)心，API預(yù)先打包），以便與你的其余代碼進行交互。
所以API可以是服務(wù)器、應(yīng)用程序，甚至買賣的產(chǎn)品。這就是為什么API很難解釋，即使對于每天接觸API的人來說也是如此。
也許定義API本質(zhì)的最恰當(dāng)?shù)姆椒ㄊ鞘褂脴犯叻e木。積木提供了一種簡單且結(jié)構(gòu)化的方式，讓所有積木都以同樣的方式拼接起來。同時，積木可能的組合無窮無盡。與之相仿，軟件可以使用API來連接我們尋找的信息以及查看信息的接口，創(chuàng)建獨特的服務(wù)組合，而這些服務(wù)共同形成一個應(yīng)用程序。
樂高積木確實有助于開發(fā)人員了解API的價值。使用API，開發(fā)人員沒必要每次編寫新程序時從頭開始。他們不再需要構(gòu)建一個試圖做所有任務(wù)的核心應(yīng)用程序。相反，他們可以使用已經(jīng)創(chuàng)建的更好地完成任務(wù)的組件，將某些責(zé)任分包出去。所以API是軟件開發(fā)界的樂高積木：這種標(biāo)準(zhǔn)化的工具便于軟件與其他軟件聯(lián)系，因而加快構(gòu)建和部署，還能為每個人縮短加載時間。
分享題目：API難解釋？這次用啤酒和積木來破局
URL標(biāo)題：http://m.5511xx.com/article/dhjeoip.html
