這種方法專注于信息的集中管理，通常使用集成平臺（ESB）作為集中收集信息并提供給最終接收者的基礎。它集中并復用日志記錄、錯誤處理和事務等組件。雖然這種方法比 P2P 更高效，但在應對當前數字化轉型的要求時仍不夠高效，因為其上市時間仍然較長。 這種方法專注于信息的集中管理，通常使用集成平臺（ESB）作為集中收集信息并提供給最終接收者的基礎。它集中并復用日志記錄、錯誤處理和事務等組件。雖然這種方法比 P2P 更高效，但在應對當前數字化轉型的要求時仍不夠高效，因為其上市時間仍然較長。
為了克服這些問題，API 主導的連接方法應運而生。
API 主導的連接方法基于 Pace 分層，目的是使集成流程能夠被多方及集成平臺內部重用。通過現有邏輯的可重用性，開發人員可以更快、更安全地改進邏輯，縮短上市時間。API 是分層構建的，與 E2E 方法相比，其主要優點在于可以重用更多的組件，使新系統和服務更易實現。
研究表明，API 主導的連接方法使開發過程加快了 3 倍，從而縮短了上市時間。由于可重用 API 已經過測試，因此使用它們可以減少新實現中的錯誤。縮短開發時間的同時也降低了集成成本，統計數據表明約降低了 70%。
在這種方法中，API 基于三個不同的層次：系統層、流程層和體驗層。通過 API 主導的架構，組織的 IT 基礎架構大致如下：
系統層是三層架構的基礎。這些 API 可以針對組織的各個領域進行定義，例如 ERP、關鍵客戶、計費系統、專有數據庫等。系統 API 提供了訪問底層記錄系統并以規范格式公開數據的方式，定義契約（如 RAML/WSDL）來描述如何與域交互。例如，客戶域的系統 API 可以包含具有 GET、POST、PUT 和 DELETE 等方法的資源，以及相關的架構（XSD、JSON）和響應（200、400、500 等）。
系統 API 通常暴露組織的敏感信息，因此不應公開使用。
流程層 API 負責通過調用多個系統 API 來編排和組織各種數據，以便塑造數據。編排包括數據的聚合、拆分和路由。流程 API 的主要目的是封裝業務流程，使其與數據來源（系統 API）獨立。例如，采購訂單流程需要與多個領域進行交互，流程 API（如采購訂單/訂單履行）會與現有系統 API 交互以實現邏輯。
流程 API 應保密，不應公開使用。
系統 API 公開了組織的敏感信息，流程 API 公開了業務流程邏輯，而業務流程數據需要以不同格式為不同的客戶或渠道所用。例如，訂單購買 API（流程層）提供 JSON 格式的數據，但某些客戶端可能只接受 XML 格式。此類轉換邏輯由體驗層 API 負責，體驗層 API 可以重新配置數據以滿足多個受眾需求，并只公開必要的方法。
體驗 API 應該公開供使用，簡而言之，它們是組織采用 API 主導的連接方法的最終產品。體驗 API 也可以通過策略應用來貨幣化，為組織賺取收入。
系統 API 的獨立性使得可以在不影響其他 API（流程和體驗）的情況下修改其邏輯。例如，如果系統 API 使用 SAP，將來需要替換為 Salesforce，只需修改系統 API，即可輕松完成替換，而無需更改流程層和體驗層中的任何內容。
流程 API 的通用業務邏輯可以在整個組織內共享。例如，已實施的采購訂單流程 API 可以在其他場景中復用，從而提高效率。
體驗 API 的作用主要是數據轉換，適應不同格式的需求。因此，可以快速滿足廣泛客戶對不同數據格式的要求，縮短上市時間。
API 主導的連接方法為現代組織的數字化轉型提供了更快、更靈活的解決方案。通過系統層、流程層和體驗層的分層架構，企業可以有效地管理和重用其 API，減少開發和集成的時間和成本，提升業務靈活性。系統 API 提供了與底層系統的抽象交互，流程 API 封裝了業務邏輯，而體驗 API 則確保了多樣化的用戶需求得到滿足。API 主導的連接不僅能夠顯著縮短上市時間，還能為企業的長期數字化戰略打下堅實的基礎。
原文鏈接：API-Led Connectivity