應(yīng)用程序編程接口（通常簡稱為API）能夠解鎖數(shù)據(jù)，使企業(yè)能夠連接系統(tǒng)、應(yīng)用程序、設(shè)備和數(shù)據(jù)集。基于多個因素——如預(yù)期用例、誰將使用和訪問這些API以及需要連接的系統(tǒng)和數(shù)據(jù)集——來確定哪種類型的API最適合某個項目至關(guān)重要。為了實現(xiàn)有效的API性能和API管理，確定要構(gòu)建的API的最佳類型并根據(jù)此設(shè)計架構(gòu)是至關(guān)重要的。

按目的劃分的API類型

組織很少會突然決定需要API——大多數(shù)情況下，組織是從一個想法、應(yīng)用程序、創(chuàng)新或用例開始的，這些想法或用例需要與其他系統(tǒng)或數(shù)據(jù)集進(jìn)行連接。

API的作用就是實現(xiàn)需要集成的系統(tǒng)和數(shù)據(jù)集之間的連接。

組織可能會為不同的目的使用不同類型的API：從內(nèi)部公開核心系統(tǒng)的功能，到啟用面向客戶的移動應(yīng)用程序。API引領(lǐng)的連接方法包括三類API：

• 系統(tǒng)API：系統(tǒng)API解鎖組織內(nèi)部核心記錄系統(tǒng)中的數(shù)據(jù)。API可以從中解鎖數(shù)據(jù)的關(guān)鍵系統(tǒng)示例包括企業(yè)資源規(guī)劃（ERP）、客戶和計費系統(tǒng)以及專有數(shù)據(jù)庫。

• 流程API：流程API與單個系統(tǒng)或跨系統(tǒng)中的數(shù)據(jù)進(jìn)行交互和塑形——打破數(shù)據(jù)孤島。流程API提供了一種將數(shù)據(jù)組合起來并為特定業(yè)務(wù)目的協(xié)調(diào)多個系統(tǒng)API的手段。這方面的示例包括創(chuàng)建客戶的360度視圖、訂單履行和發(fā)貨狀態(tài)。

• 體驗API：體驗API為通過系統(tǒng)和流程API解鎖和建立的數(shù)據(jù)和流程提供業(yè)務(wù)上下文。體驗API將數(shù)據(jù)暴露給預(yù)期受眾以供使用——例如移動應(yīng)用程序、客戶數(shù)據(jù)的內(nèi)部門戶等。

  
  

API管理策略的類型

一旦你確定了組織API的用例，接下來就要確定誰將訪問這些API。大多數(shù)情況下，用例和預(yù)期用戶是相輔相成的——例如，你可能希望將客戶數(shù)據(jù)呈現(xiàn)給內(nèi)部銷售和服務(wù)代理（在這種情況下，預(yù)期最終用戶是內(nèi)部員工）。

以下是基于管理方式和訪問者的三種API類型：

外部API

外部API可以被組織外部的第三方（開發(fā)人員、合作伙伴等）訪問。它們通常使全球的開發(fā)人員能夠輕松自助地訪問組織的數(shù)據(jù)和服務(wù)，這些開發(fā)人員希望創(chuàng)建創(chuàng)新的應(yīng)用程序和集成。

一個開放API的例子是谷歌地圖API，它在第三方應(yīng)用程序（如拼車應(yīng)用和送餐應(yīng)用）中被廣泛使用，以實現(xiàn)位置跟蹤和地圖繪制。

內(nèi)部API

內(nèi)部API與開放API相反，它們對外部用戶不可訪問，僅供組織內(nèi)部開發(fā)人員使用。內(nèi)部API可以支持從采用DevOps和微服務(wù)架構(gòu)到遺留系統(tǒng)現(xiàn)代化和數(shù)字轉(zhuǎn)型等全企業(yè)范圍的舉措。這些API的使用和重用可以提高組織的生產(chǎn)力、效率和敏捷性。

一個可重用的內(nèi)部API的例子是，呼叫中心團(tuán)隊創(chuàng)建了一個用于呼叫中心應(yīng)用程序的客戶信息API，用于訪問客戶的姓名、聯(lián)系信息、賬戶信息等。然后，該團(tuán)隊可以在面向客戶的Web應(yīng)用程序或移動應(yīng)用程序中重用相同的API。

合作伙伴API

合作伙伴API介于內(nèi)部API和外部API之間。它們是由具有專屬權(quán)限的組織外部人員訪問的API。通常，這種特殊訪問權(quán)限會授予特定的第三方，以促進(jìn)戰(zhàn)略業(yè)務(wù)合作。

合作伙伴API的一個常見用例是兩個組織希望相互共享數(shù)據(jù)——例如，一個縣的衛(wèi)生部門和該縣內(nèi)的一家醫(yī)院。將設(shè)置合作伙伴API，以便每個組織都可以使用正確的憑據(jù)和權(quán)限訪問必要的數(shù)據(jù)。

API架構(gòu)風(fēng)格類型

API的另一個選擇領(lǐng)域是采用哪種架構(gòu)風(fēng)格或風(fēng)格組合。如果需要某些功能，選擇最能支持API預(yù)期用途的架構(gòu)風(fēng)格或模式至關(guān)重要。這往往是由技術(shù)傾向更強(qiáng)的團(tuán)隊做出的API設(shè)計決策。

在做出這個決定之前，你需要對已經(jīng)存在的基礎(chǔ)設(shè)施有一個基本的了解——系統(tǒng)是在本地還是在云端，需要使用哪些系統(tǒng)和數(shù)據(jù)集，需要實施哪些安全協(xié)議，以及需要哪些功能。在API優(yōu)先設(shè)計的理念下，期望的功能和用戶體驗應(yīng)該指導(dǎo)對遺留IT資產(chǎn)的更改，而不是讓遺留IT資產(chǎn)的現(xiàn)狀來決定功能或體驗。

API有多種架構(gòu)風(fēng)格，以及這些風(fēng)格內(nèi)的不同數(shù)據(jù)格式，以下列出了一些最常見的：

• REST：REST（Representational State Transfer，表述性狀態(tài)轉(zhuǎn)移）是一種架構(gòu)風(fēng)格，它通過依賴內(nèi)置于底層網(wǎng)絡(luò)協(xié)議的命令，將API消費者和API提供者的關(guān)注點分離。客戶端使用包含的鏈接和表單來執(zhí)行操作（例如讀取、更新、共享、批準(zhǔn)等）。HTML是這種風(fēng)格最著名的例子，還有幾種專為API設(shè)計的格式（如HAL、CollectionJSON、Siren等）。REST API有許多優(yōu)點，包括靈活性，以及能夠容納JSON和XML等流行的數(shù)據(jù)格式。

• RPC：遠(yuǎn)程過程調(diào)用（Remote Procedure Calls，RPC）通常要求開發(fā)人員在其他系統(tǒng)上執(zhí)行特定的代碼塊。RPC風(fēng)格的遠(yuǎn)程過程調(diào)用通常需要開發(fā)人員按名稱調(diào)用這些過程。RPC與協(xié)議無關(guān)，這意味著它可以在許多協(xié)議上得到支持，但也失去了使用原生協(xié)議功能（如緩存）的好處。從一個RPC API到下一個RPC API的非標(biāo)準(zhǔn)過程名稱的激增，導(dǎo)致API消費者和提供者之間的耦合更加緊密，從而加重了參與RPC驅(qū)動API生態(tài)系統(tǒng)各個方面的開發(fā)人員的負(fù)擔(dān)。RPC架構(gòu)模式可以在流行的API技術(shù)中觀察到，如SOAP、GraphQL和gRPC。

• 事件驅(qū)動/流式處理：有時被稱為事件觸發(fā)、實時、流式處理、異步或推送架構(gòu)，事件驅(qū)動API在交付響應(yīng)之前不會等待API消費者調(diào)用它們。相反，響應(yīng)是由事件的發(fā)生觸發(fā)的。這些服務(wù)公開事件，客戶端可以訂閱這些事件，以便在服務(wù)上的值更改時接收更新。這種風(fēng)格有許多變體，包括（但不限于）響應(yīng)式、發(fā)布-訂閱、事件通知和CQRS（命令查詢責(zé)任分離）。

  
  

我們周圍充斥著各種適合這種API模式的事件。以下是其中的幾個例子：

一個抖音賬戶發(fā)布了一條新視頻。

一個遠(yuǎn)程溫度計的溫度發(fā)生了變化。

一輛車駛過路面上的傳感器。

一個安全攝像頭在其視野內(nèi)檢測到運動。

一臺心電圖機(jī)檢測到心跳不規(guī)則。

一個緊急出口門被打開。

一個煙霧探測器檢測到煙霧。

設(shè)計和管理有效的API需要考慮許多因素。上述內(nèi)容應(yīng)概述了組織在準(zhǔn)備設(shè)計、部署和管理API時需要做出的不同決策。