API 由一組定義和協(xié)議組合而成，可用于構(gòu)建和集成應(yīng)用軟件。API 是“應(yīng)用編程接口”的縮寫(xiě)。
通過(guò) API，就算您不知道如何操作，也能將您的產(chǎn)品或服務(wù)與其他的互通。這樣可以簡(jiǎn)化應(yīng)用的開(kāi)發(fā)，節(jié)省時(shí)間和成本。在您開(kāi)發(fā)新的工具和產(chǎn)品，或管理現(xiàn)有工具和產(chǎn)品時(shí)，強(qiáng)大靈活的 API 可以幫助您簡(jiǎn)化設(shè)計(jì)、管理和使用，并帶來(lái)更多創(chuàng)新機(jī)遇。
API 有時(shí)被視為合同，而合同文本則代表了各方之間的協(xié)議：如果一方以特定方式發(fā)送遠(yuǎn)程請(qǐng)求，該協(xié)議規(guī)定了另一方的軟件將如何做出響應(yīng)。 由于 API 簡(jiǎn)化了開(kāi)發(fā)人員將新應(yīng)用組件集成到現(xiàn)有基礎(chǔ)架構(gòu)中的方式，繼而也對(duì)業(yè)務(wù)和 IT 團(tuán)隊(duì)之間的協(xié)作提供了幫助。
隨著數(shù)字市場(chǎng)日新月異，業(yè)務(wù)需求通常也會(huì)出現(xiàn)迅速變化，新的競(jìng)爭(zhēng)對(duì)手利用新的應(yīng)用即可改變整個(gè)行業(yè)。為了保持競(jìng)爭(zhēng)力，支持快速開(kāi)發(fā)和部署創(chuàng)新服務(wù)尤為重要。云原生應(yīng)用開(kāi)發(fā)是提高開(kāi)發(fā)速度的一個(gè)明確辦法，依賴(lài)于通過(guò) API 連接 微服務(wù)應(yīng)用架構(gòu)。
API 是通過(guò)云原生應(yīng)用開(kāi)發(fā)來(lái)連接您自己的基礎(chǔ)架構(gòu)的一個(gè)簡(jiǎn)化方式，此外還支持您向客戶和其他外部用戶分享您的數(shù)據(jù)。公共 API 有著獨(dú)特的商業(yè)價(jià)值，因其可以簡(jiǎn)化和擴(kuò)展您與合作伙伴的聯(lián)系方式，并有望支持您從數(shù)據(jù)中實(shí)現(xiàn)盈利（Google Maps API 便是其中一個(gè)廣為人知的案例）。
例如，我們假設(shè)有這樣一家圖書(shū)發(fā)行公司：該發(fā)行商可以提供一個(gè)應(yīng)用，供書(shū)店店員查看書(shū)的庫(kù)存情況。這款應(yīng)用的開(kāi)發(fā)成本高昂、有平臺(tái)限制、開(kāi)發(fā)周期較長(zhǎng)，還需進(jìn)行日常維護(hù)。 或者，該發(fā)行商也可以提供一個(gè) API 來(lái)查詢(xún)庫(kù)存情況。這一方法有以下幾個(gè)好處： API 可以幫助他們將所有庫(kù)存相關(guān)信息匯集到一處，供客戶方便地訪問(wèn)數(shù)據(jù)。 只要 API 的行為不發(fā)生變化，該圖書(shū)發(fā)行商就能在不影響客戶的情況下更改內(nèi)部系統(tǒng)。 借助公開(kāi)可用的 API，開(kāi)發(fā)人員可為該圖書(shū)發(fā)行商、圖書(shū)銷(xiāo)售商或第三方開(kāi)發(fā)一個(gè)應(yīng)用，幫助客戶查找所需的圖書(shū)。這樣不僅能提高銷(xiāo)量，還能帶來(lái)其他的商機(jī)。
簡(jiǎn)而言之，API 既能讓您開(kāi)放自己的資源訪問(wèn)權(quán)限，又能確保安全性并讓您繼續(xù)握有控制權(quán)。如何以及向誰(shuí)開(kāi)放訪問(wèn)權(quán)限則由您來(lái)決定。良好的 API 管理是 API 安全性的關(guān)鍵所在。借助通聯(lián)各種資源（包括傳統(tǒng)系統(tǒng)和物聯(lián)網(wǎng)）的分布式集成平臺(tái)，您可以連接至 API 并創(chuàng)建使用 API 提供的數(shù)據(jù)或功能的應(yīng)用。
API 的發(fā)布策略共有三種方案可供選擇。
私有：這類(lèi) API 僅供內(nèi)部使用，能讓公司最大限度地控制自己的 API。
合作伙伴：您會(huì)和特定的業(yè)務(wù)合作伙伴共享這類(lèi) API。它能在不影響質(zhì)量的情況下帶來(lái)額外收益。
公共：這類(lèi) API 可供所有人使用。第三方可以使用這類(lèi) API 來(lái)開(kāi)發(fā)應(yīng)用，以便與您的 API 進(jìn)行互動(dòng)或?qū)崿F(xiàn)某種創(chuàng)新。
利用 API 實(shí)現(xiàn)創(chuàng)新 通過(guò)向合作伙伴或公眾提供您的 API，可以： 創(chuàng)造新的收入渠道，或拓展現(xiàn)有收入渠道。 擴(kuò)大您的品牌覆蓋范圍。 通過(guò)外部開(kāi)發(fā)和協(xié)作，推動(dòng)開(kāi)放創(chuàng)新或提高效率。
聽(tīng)上去還不錯(cuò)，對(duì)嗎？但是，API 是如何做到上述幾點(diǎn)的呢？ 我們繼續(xù)以剛才的那個(gè)圖書(shū)發(fā)行公司為例。 假設(shè)該公司的某個(gè)合作伙伴開(kāi)發(fā)了一個(gè)應(yīng)用，可以幫助人們查找書(shū)店書(shū)架上的圖書(shū)。這種體驗(yàn)的改進(jìn)為書(shū)店帶來(lái)了更多的客戶（該發(fā)行商的客戶），并拓展了現(xiàn)有的收入渠道。
或許會(huì)有第三方使用某個(gè)公共 API 來(lái)開(kāi)發(fā)應(yīng)用，以便人們直接從該發(fā)行商處（而非書(shū)店）購(gòu)書(shū)。這樣就能為該圖書(shū)發(fā)行商打開(kāi)新的收入渠道。
與特定合作伙伴或全世界共享 API 能帶來(lái)積極的影響。除了自己公司的營(yíng)銷(xiāo)活動(dòng)之外，每一個(gè)合作關(guān)系都能幫助您提高品牌辨識(shí)度。以公共 API 的形式向所有人開(kāi)放技術(shù)，可以激勵(lì)開(kāi)發(fā)人員以您的 API 為中心構(gòu)建應(yīng)用生態(tài)系統(tǒng)。有更多的人使用您的技術(shù)，就意味著可能會(huì)有更多的人與您做生意。
公開(kāi)技術(shù)可以帶來(lái)意外之喜。有時(shí)，這些驚喜更會(huì)顛覆整個(gè)行業(yè)。對(duì)于這家圖書(shū)發(fā)行公司而言，新形態(tài)的公司（比如圖書(shū)出借服務(wù)）可能會(huì)完全改變他們的業(yè)務(wù)模式。借助合作伙伴和公共 API，您可以激發(fā)社區(qū)成員的創(chuàng)意（其人數(shù)遠(yuǎn)超您的內(nèi)部開(kāi)發(fā)團(tuán)隊(duì)）。各種奇思妙想會(huì)源源不斷地涌現(xiàn)，公司只需明辨市場(chǎng)的變化情況并做好相應(yīng)的準(zhǔn)備。API 大有用處。
API 簡(jiǎn)史
API 概念的出現(xiàn)，始于計(jì)算機(jī)時(shí)代的初期，遠(yuǎn)遠(yuǎn)早于個(gè)人電腦誕生之前。當(dāng)時(shí)，API 常被當(dāng)作操作系統(tǒng)的庫(kù)，而且基本上都在本地系統(tǒng)上運(yùn)行，僅偶爾用于大型機(jī)之間傳遞消息。將近 30 年后，API 走出了它們的本地環(huán)境。到了 21 世紀(jì)初，API 成為了用于實(shí)現(xiàn)數(shù)據(jù)遠(yuǎn)程集成的一種重要技術(shù)。
遠(yuǎn)程 API
遠(yuǎn)程 API 旨在通過(guò)通信網(wǎng)絡(luò)進(jìn)行互動(dòng)。這里的“遠(yuǎn)程”是指 API 操控的資源不在提出請(qǐng)求的計(jì)算機(jī)上。由于互聯(lián)網(wǎng)是應(yīng)用最廣泛的通信網(wǎng)絡(luò)，所以大多數(shù) API 都是基于 Web 標(biāo)準(zhǔn)來(lái)設(shè)計(jì)的。并非所有的遠(yuǎn)程 API 都是 Web API，但可以認(rèn)為 Web API 都是遠(yuǎn)程 API。
Web API 通常會(huì)使用 HTTP 來(lái)傳輸請(qǐng)求消息，并提供響應(yīng)消息的結(jié)構(gòu)定義。這些響應(yīng)消息通常都會(huì)以 XML 或 JSON 文件的形式來(lái)提供。XML 和 JSON 都是首選格式，因?yàn)樗鼈儠?huì)以易于其他應(yīng)用操縱的方式來(lái)呈現(xiàn)數(shù)據(jù)。
API 經(jīng)過(guò)哪些改進(jìn)？
在 API 逐步發(fā)展成為當(dāng)前隨處可見(jiàn)的 Web API 的過(guò)程中，人們對(duì)它進(jìn)行了一些改進(jìn)，簡(jiǎn)化了設(shè)計(jì)并改進(jìn)了它的實(shí)施成效。
少些 SOAP，多些 REST
隨著 Web API 的不斷普及，相應(yīng)的協(xié)議規(guī)范也隨之產(chǎn)生了，從而推動(dòng)了信息交換的標(biāo)準(zhǔn)化：簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議，簡(jiǎn)稱(chēng) SOAP。使用 SOAP 設(shè)計(jì)的 API 會(huì)使用 XML 格式來(lái)收發(fā)消息，并通過(guò) HTTP 或 SMTP 來(lái)接收請(qǐng)求。使用 SOAP 時(shí)，在不同環(huán)境中運(yùn)行的應(yīng)用或使用不同語(yǔ)言編寫(xiě)的應(yīng)用能夠更加輕松地共享信息。
相關(guān)的規(guī)范還有一個(gè)，即：表述性狀態(tài)傳遞（REST）。遵循 REST 架構(gòu)約束的 Web API 被稱(chēng)為 RESTful API。REST 與 SOAP 有著根本區(qū)別：SOAP 是一種協(xié)議，而 REST 是一種架構(gòu)模式。這意味著 RESTful Web API 沒(méi)有官方標(biāo)準(zhǔn)。正如 Roy Fielding 在論文“Architectural Styles and the Design of Network-based Software Architectures”（架構(gòu)模式以及基于網(wǎng)絡(luò)的軟件架構(gòu)的設(shè)計(jì)）中定義的那樣，只要 API 符合 RESTful 系統(tǒng)的 6 個(gè)導(dǎo)向性約束，就算作 RESTful API：
客戶端/服務(wù)器架構(gòu)：REST 架構(gòu)由客戶端、服務(wù)器和資源構(gòu)成，通過(guò) HTTP 來(lái)處理請(qǐng)求。
無(wú)狀態(tài)：請(qǐng)求所經(jīng)過(guò)的服務(wù)器上不會(huì)存儲(chǔ)任何客戶端內(nèi)容。與會(huì)話狀態(tài)相關(guān)的信息會(huì)存儲(chǔ)在客戶端上。 可緩存性：通過(guò)緩存，可免去客戶端與服務(wù)器之間的某些交互。
分層系統(tǒng)：客戶機(jī)與服務(wù)器之間的交互可以通過(guò)額外的層來(lái)進(jìn)行調(diào)解。這些層可以提供額外的功能，如負(fù)載均衡、共享緩存或安全防護(hù)。
按需代碼（可選）：服務(wù)器可通過(guò)傳輸可執(zhí)行代碼來(lái)擴(kuò)展客戶端的功能。
統(tǒng)一接口：這項(xiàng)約束是 RESTful API 的設(shè)計(jì)核心，共涵蓋 4 個(gè)層面：
識(shí)別請(qǐng)求中的資源：請(qǐng)求中的資源會(huì)被識(shí)別，并與返回給客戶端的表示內(nèi)容分離開(kāi)來(lái)。
通過(guò)不同的表示內(nèi)容來(lái)操縱資源：客戶端會(huì)收到表示不同資源的文件。這些表示內(nèi)容必須提供足夠的信息，以便執(zhí)行修改或刪除操作。
自描述消息：返回給客戶端的每個(gè)消息都包含充足的信息，用于指明客戶端應(yīng)該如何處理所收到的信息。
將超媒體作為應(yīng)用狀態(tài)的引擎：在訪問(wèn)某個(gè)資源后，REST 客戶端應(yīng)該能夠通過(guò)超鏈接來(lái)發(fā)現(xiàn)當(dāng)前可用的所有其他操作。
雖然看似有很多約束需要遵循，但是這些約束遵循起來(lái)要比遵循規(guī)定的協(xié)議容易得多。因此，RESTful API 現(xiàn)在變得比 SOAP 更為普及。
近年來(lái)，OpenAPI 規(guī)范已成為定義 REST API 的通用標(biāo)準(zhǔn)。OpenAPI 為開(kāi)發(fā)人員提供了一種與語(yǔ)言無(wú)關(guān)的方式來(lái)構(gòu)建 REST API 接口，從而最大程度減少不確定的因素，讓用戶安心工作。
SOA 與微服務(wù)架構(gòu)
最常使用遠(yuǎn)程 API 的 2 種架構(gòu)方案分別是：面向服務(wù)的架構(gòu)（SOA）和微服務(wù)架構(gòu)。在這 2 種方案中，SOA 的歷史更為久遠(yuǎn)一些。最初，它是在單體式應(yīng)用的基礎(chǔ)上經(jīng)過(guò)改進(jìn)而形成的。雖然單個(gè)單體式應(yīng)用也可以完成各種操作，但通過(guò)某種集成模式（如企業(yè)服務(wù)總線（ESB））在不同應(yīng)用間實(shí)現(xiàn)松散耦合后，即可獲得某些功能。
從大多數(shù)層面來(lái)看，SOA 都要比單體式架構(gòu)更簡(jiǎn)單；但是，如果無(wú)法明確理解各種組件交互，SOA 也可能會(huì)進(jìn)一步加劇整個(gè)環(huán)境的復(fù)雜性。這種復(fù)雜性的加劇會(huì)重新引發(fā) SOA 想要解決的某些問(wèn)題。
對(duì)于專(zhuān)用松散耦合服務(wù)的使用，微服務(wù)架構(gòu)與 SOA 模式類(lèi)似。但是，微服務(wù)架構(gòu)會(huì)對(duì)傳統(tǒng)架構(gòu)進(jìn)行進(jìn)一步細(xì)分。在微服務(wù)架構(gòu)中，服務(wù)會(huì)采用通用消息傳遞框架，如 RESTful API。它們會(huì)使用 RESTful API 來(lái)實(shí)現(xiàn)相互通信，且無(wú)需執(zhí)行繁瑣的數(shù)據(jù)轉(zhuǎn)換處理或使用其他的集成層。使用 RESTful API 可以加速新功能和新更新的交付；甚至還可以說(shuō)，是這類(lèi) API 促進(jìn)了這種速度的提升。該架構(gòu)中的每一個(gè)服務(wù)都呈離散狀態(tài)。一個(gè)服務(wù)可以被取代、增強(qiáng)或丟棄，而不會(huì)影響架構(gòu)中的任何其他服務(wù)。這種輕量級(jí)架構(gòu)有助于優(yōu)化分布式資源或云資源，而且能夠支持個(gè)別服務(wù)的動(dòng)態(tài)擴(kuò)展。
