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

按目的劃分的API類型

組織很少會突然決定需要API——大多數情況下，組織是從一個想法、應用程序、創新或用例開始的，這些想法或用例需要與其他系統或數據集進行連接。

API的作用就是實現需要集成的系統和數據集之間的連接。

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

• 系統API：系統API解鎖組織內部核心記錄系統中的數據。API可以從中解鎖數據的關鍵系統示例包括企業資源規劃（ERP）、客戶和計費系統以及專有數據庫。

• 流程API：流程API與單個系統或跨系統中的數據進行交互和塑形——打破數據孤島。流程API提供了一種將數據組合起來并為特定業務目的協調多個系統API的手段。這方面的示例包括創建客戶的360度視圖、訂單履行和發貨狀態。

• 體驗API：體驗API為通過系統和流程API解鎖和建立的數據和流程提供業務上下文。體驗API將數據暴露給預期受眾以供使用——例如移動應用程序、客戶數據的內部門戶等。

  
  

API管理策略的類型

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

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

外部API

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

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

內部API

內部API與開放API相反，它們對外部用戶不可訪問，僅供組織內部開發人員使用。內部API可以支持從采用DevOps和微服務架構到遺留系統現代化和數字轉型等全企業范圍的舉措。這些API的使用和重用可以提高組織的生產力、效率和敏捷性。

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

合作伙伴API

合作伙伴API介于內部API和外部API之間。它們是由具有專屬權限的組織外部人員訪問的API。通常，這種特殊訪問權限會授予特定的第三方，以促進戰略業務合作。

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

API架構風格類型

API的另一個選擇領域是采用哪種架構風格或風格組合。如果需要某些功能，選擇最能支持API預期用途的架構風格或模式至關重要。這往往是由技術傾向更強的團隊做出的API設計決策。

在做出這個決定之前，你需要對已經存在的基礎設施有一個基本的了解——系統是在本地還是在云端，需要使用哪些系統和數據集，需要實施哪些安全協議，以及需要哪些功能。在API優先設計的理念下，期望的功能和用戶體驗應該指導對遺留IT資產的更改，而不是讓遺留IT資產的現狀來決定功能或體驗。

API有多種架構風格，以及這些風格內的不同數據格式，以下列出了一些最常見的：

• REST：REST（Representational State Transfer，表述性狀態轉移）是一種架構風格，它通過依賴內置于底層網絡協議的命令，將API消費者和API提供者的關注點分離。客戶端使用包含的鏈接和表單來執行操作（例如讀取、更新、共享、批準等）。HTML是這種風格最著名的例子，還有幾種專為API設計的格式（如HAL、CollectionJSON、Siren等）。REST API有許多優點，包括靈活性，以及能夠容納JSON和XML等流行的數據格式。

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

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

  
  

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

一個抖音賬戶發布了一條新視頻。

一個遠程溫度計的溫度發生了變化。

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

一個安全攝像頭在其視野內檢測到運動。

一臺心電圖機檢測到心跳不規則。

一個緊急出口門被打開。

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

設計和管理有效的API需要考慮許多因素。上述內容應概述了組織在準備設計、部署和管理API時需要做出的不同決策。