成熟度模型分為7個級別，分為3個常規分類：

• 不基於API：  系統和整合體系結構不基於正式API，在某些情況下沒有通訊，而其他通常共享檔案，使用佇列，非結構化Web服務甚至製作一些TCP / Socket技術以提供應用程式之間的通訊。
• 部分基於API：  系統和整合體系結構部分基於API，這意味著使用Service Repository和Developer Portal等資源對SOAP和RESTful Web服務進行了廣泛使用，但治理程度低，標準化和關注點分離（API和服務之間）。
• 完全基於API：  系統和整合體系結構完全基於API，這意味著在API，服務和應用程式等層之間存在關注點分離。從業務角度看，API是新業務模型的基礎，或者業務本身依賴於API。還觀察到其他技術特徵和功能，例如強大的安全機制，API治理，監視，分析措施以及改進的API開發人員體驗。

級別1：隔離的應用程式

在這種情況下，系統架構基於無/低整合的隔離應用程式。應用程式的主要型別為：整體應用程式，現成的應用程式（如ERP或CRM）。

級別2：非結構化整合

應用程式之間有整合，但是它們是非結構化的，這意味著沒有訊息結構甚至使用技術的標準。此外，整合渠道是分散的（點對點），沒有集線器或某種匯流排-整合是臨時建立的，可以解決特定問題。通常使用的技術有：

• 訊息佇列
• Socket連線
• 資料庫複製
• 檔案共享（例如XML，CSV或EDI）

級別3：基於元件的體系結構

此級別指的是基於元件的系統架構，此處使用的主要架構模型為：

• EJB（企業Java Bean）
• CORBA
• Microsoft COM / COM + / DCOM
• 獨立的Web服務應用程式

主要整合技術為：

• TCP /套接字（例如Java RMI，COM​​，EJB）
• 定製Socket連線
• HTTP端點（例如SOAP，HTTP上的RPC）

在此級別中發現的主要問題是：整合和介面沒有互操作性或互操作性很差，因為所使用的技術僅與另一側的同一技術通訊。Web服務是一個例外，但是通常它們不遵循標準，並且沒有任何形式的治理，這使得互操作性難以維護。

級別4：面向服務的體系結構

在此級別上，系統體系結構實現了SOA原理，例如，服務層和業務應用層之間的關注點分離。通常，應用層涉及業務和資料儲存功能，服務層涉及合同/介面標準化，抽象，可組合性，發現等。

系統架構的主要特徵是：

• 單體應用程式（應用程式層）
• SOA堆疊（ESB，BPEL，複雜事件處理器，服務暫存器等）
• 本地基礎架構

整合技術為：

• SOAP Web服務
• RESTFul Web服務（但初期使用）
• 訊息傳遞（例如，JMS，ActiveMQ等）

最後，與此級別相關的主要問題是：雖然服務層與應用層分離了，但是服務層和API層之間沒有關注點分離（請參見下圖），服務層也包含一些API功能。

級別5：基於微服務架構的私有API

在這個級別上，系統架構使用微服務方法。通常有兩種型別的層：微服務所駐留的前端層和後端層，在這種架構中，API閘道器的作用在某些情況下似乎是為了提供前端和後端之間的整合。由於只有內部前端應用程式使用這些API，因此我們將其歸類為私有API。

系統架構的主要特徵是：

• 微服務模式的使用
• API閘道器
• 主要基於雲基礎架構和容器。
• 網狀Mesh架構的初期使用

使用的主要整合技術是：

• RESTful API（暴露於前端，甚至微服務之間的通訊）
• AMQP（例如Kafka，RabbitMQ等）
• 最初使用新的通訊協議，例如gRPC，Thrift等。

但是，此級別與API相關的關鍵問題是：API未被完全管理。僅使用一些功能，例如安全性和節流功能，這些功能由API閘道器提供。另一個重要特徵是，也不管理微服務公開的API，這意味著通訊是點對點的，沒有集中管理（缺少網格體系結構功能）。

要觀察的另一點是，該體系結構基於單個API閘道器，這不容易擴充套件到整個公司，強烈建議採用API平臺來維持這種體系結構的發展。

由於上述所有問題，我們將此級別分類為部分基於API。

級別6：開放式API

在這個級別上，公司通常具有其他級別的一些技術特徵，但是主要技術特徵是在其他之上具有API層。

在這種情況下，API是業務的重要組成部分，因為它支援業務增長。公司可以建立合作伙伴生態系統和開放的創新環境，以支援創造新的價值流和創新服務。

從技術角度看，可以觀察到其他特徵：

• 商業或開源API平臺及其模組的使用
• 使用開發人員入口網站來增加合作伙伴和初創公司的開發人員體驗
• 使用Google Analytics（分析）模組監控技術和業務行為
• 應用WAF和DDoS保護的強大安全約束。
• RESTful API作為外部整合的標準。

級別7：API作為業務

顧名思義，在此級別的公司完全基於API來執行其業務。

以下是必須遵守的技術特徵：

• 強大的API策略
• 全面控制外部和內部API（包括服務和微服務之間）
• 使用API​​平臺的全部功能
• 嚴格遵守法規（例如PSD2）
• 使用服務網格的成熟的微服務架構
• 強大的基於雲的基礎架構和基礎
• 多種託管通訊協議，例如RESTful，GraphQL，WebSockets，gRPC等。

成熟路線圖

一旦評估了公司並瞭解了公司的當前水平和期望水平，就可以建立發展路線圖，當然，此計劃的細節取決於各種因素，例如業務驅動因素，技術約束和未來前景。

但是，在建立計劃時，建議您考慮一些技巧，例如：

• 首先，請從4級移至5級，而不是從4級移至7級，寶貝！
• 選擇一個MVP專案來驗證您的假設，從小做起，測試，學習和應用建議
• 從內部和受控API開始
• 定義一些API模式並建立最小的API治理。

結論

實際上，要以某種形式參與API經濟，您的公司需要針對內部或外部上下文管理您的API。無論貴公司位於哪個級別，公司都可以啟動API策略的建立，例如，以建立基於API的合作伙伴生態系統為目標。

本文的主要重點是指出基於某些場景的體系結構有多成熟，以瞭解要實施的最佳技術解決方案和技術策略，以便根據業務和技術要求提供成熟的API體系結構。