API First 在跨企業的系統交互越來越頻繁的今天，提供有效的擴展業務的方法。過往什麼功能都要自行開發，但卻因為內部資源不足；亦或錯估新業務規模的深度與需求層次，造成投入沒有成效、或者必須不斷的加碼投入，最後才意會到，這是個獨立領域，需要獨立的專業團隊，像是 MarTech、支付、通訊 …

API First 的概念，背後是雙方在技術上彼此溝通的通訊協議，透過這層協議，雙方可以更快速的仰賴彼此的擅長的領域，進而拓展業務。最常見的就是電商與支付系統、廣告服務、電信系統、物流業、與 ChatBot / AI … 等整合。

開放 API 是個策略性決策，背後代表著要與合作夥伴達成策略聯盟，本質上是 B2B 的商業行為；同時開放 API 也意味著內部系統需要有高度整合，提供對外統一介面與標準，讓合作夥伴在開發過程，可以有一致性的使用介面與理解。

基於這樣的前提，只要是 API 對外開放、或者是內部整合，都要面對本文要提到的問題：API 通訊模式與協議

摘要

本文摘要基於 B2B 的業務模式，開放 API 時必須要規劃的對內、對外通訊模式，以及分析實務上的情境組合。

通訊模式

通訊模式 代表 API 對內、對外彼此交互的方式，整理如下圖：

圖中定義的系統包含如下：

1. API Platform: 主要處理的是外部通訊請求，
   • 架構角色包含 API Gateway, API Manaement, API Operation 等部分
     • API Gateway: 職責包含 AAA, Traffic Control, Protection, Rate Limit,
     • API Management: API 的 Publisher / Subscriber, Token & Key Management / Lifecycle / Documentation … 等，背後本質與核心議題是 API Governance
     • API Operation: 包含 Obervability & Monitoring, APM, Tracing, Logging, Cache … 等架構性問題.
   • 整合 API Platform 對外處理合作夥伴的 API 請求, 同時轉發請求給對應的內部服務.
   • API Platform 本身必須滿足以下架構需求: Security, Reliablity, Performance, Operational
2. Service X: 企業內部各種 Domain Services 的泛稱，像是訂單 / 商品 / 庫存 … 等.
   • 這些服務都是內部系統，不直接對外
   • 這些服務對於 API Platform 兒言，都屬於 Publisher，或稱 Provider (供應商)
   • 這些服務跟服務之間的溝通，必須遵循 內部通訊協議 (Internal Commucation Protocol, ICP)
3. External Services: 使用 API 的合作夥伴，這裡的案例是 B2B
4. Client: 提供給 End User 使用的 GUI 介面形式，包含 Mobile, Desktop, Web … 等.

這四個角色之間，彼此之間的溝通用不同顏色以及標示 (C2, B3, C4, C3, D4 … )，搭配 情境矩陣 收斂實際的範圍。

情境矩陣

這四個角色之間的通訊，有 16 種排列組合，整理出以下的情境矩陣：

這十六種排列組合，彼此之間都有可能會相互通訊，情境矩陣則展開了所有的可能，經過分析後，刪除不合理、不需要、不必要的排列組合 (A1, B2, C1 …)，確立我們需要關注的組合，最核心情境有以下：

1. Session Base: 排列組合中的 A2
2. External API: 排列組合中的 B3, C4
3. Internal Commucation: 排列組合中的 C3, D3, D4
4. External Invcation: 排列組合中的 C2, D2

有了這樣的定義與理解之後，針對每個通訊模式，就可以定義適當的 Context ，讓彼此有一致的標準溝通，包含 (但不限於) 以下：

1. 認證授權
2. 服務治理
3. 展開適當的架構設計
4. 追蹤管理
5. API 設計方法
6. API 生態系的管理與治理
7. API 維運
8. … etc.

小結

下圖是網路上很有名的故事，個人覺得核心是「經營之道」：

故事摘要如下：

第一個猶太人來到小鎮上開了個加油站，生意很旺。第二個猶太人來了，發現加油站生意很不錯，想到加油站的客戶需要吃飯，所以投資開了個餐館。第三個猶太人來了，想到來小鎮的人多了需要住宿，於是開了個飯店。第四個猶太人又發現住店的人需要生活用品，於是開了超市。第五個，第六個……來的人越來越多，吃飯住宿旅遊經商的人又需要加油，於是加油站、餐館、飯店、超市的生意相繼更旺了，逐步小鎮就成了一個經濟繁榮的小鎮，很多猶太人都富裕了。

第一個中國人來到小鎮上開了個加油站，生意很旺。第二個中國人來了，發現第一個人投資的加油站生意真令人羨慕，趕緊開了第二個加油站。第三個中國人又來了，看見前面2個同胞的加油站生意很好妒嫉得眼紅，火速開了第三個加油站。第四，第五個同胞過來都是一樣，開加油站還打折促銷……最後惡性競爭，然後紛紛倒閉，小鎮又回到原點……

先不論故事中的反諷，但是猶太人的重點就在於經營的過程，透過整合的方式，而不是硬碰硬，透過共榮、相互依存的概念，集結成一個生態系。API 本身就是生態系中的一環，企業透過開放 API，與其他異業結合，相互協助、相互依存，形成一個生態系。

有了這個核心的模式與情境，接下來就可以討論實際上架構設計時的選擇與設計思路，以及市面上的解決方案。

延伸閱讀

站內文章

• API 設計 - 摘要 API 通訊模式與協議
• API 設計 - API 整合矩陣
• Overview API Gateway
• 聊聊分散式架構的服務治理
• 摘要 Eclipse 設計的啟發：當代 SaaS 分散式架構的關鍵設計
• Shell and Bash Concepts