通訊協定
架構樣式定義了應用程式編程介面（API）的不同元件如何相互互動。因此，它們透過提供設計和構建API的標準方法，確保了效率、可靠性和與其他系統的輕松整合。
以下是最常用的樣式：
SOAP
成熟、全面、基於XML
最適合企業套用
RESTful
流行的、易於實作的HTTP方法
Web服務的理想選擇
GraphQL
查詢語言，請求特定數據
減少網路開銷，加快響應速度
gRPC
現代化的高效能協定緩衝區
適用於微服務架構
WebSocket
即時、雙向、持久連線
非常適合低延遲數據交換
Webhook
事件驅動、HTTP回呼、異步
事件發生時通知系統
REST API vs GraphQL
當涉及到API設計時，REST和GraphQL都有自己的優點和缺點。下圖顯示了REST和GraphQL之間的快速比較。
REST
使用標準的HTTP方法，如GET，POST，PUT，CRUD操作。
當您需要在獨立的服務/應用程式之間使用簡單、統一的介面時，可以很好地工作。
緩存策略很容易實作。
缺點是它可能需要多次往返才能從不同的端點收集相關數據。
GraphQL
為客戶端提供一個端點，以便精確查詢所需的數據。
客戶端指定巢狀查詢中所需的確切欄位，伺服器返回僅包含這些欄位的最佳化有效負載。
支持用於修改數據的Mutations和用於即時通知的Subscriptions。
非常適合聚合來自多個來源的數據，並能很好地滿足快速發展的前端需求。
但是，它將復雜性轉移到客戶端，如果沒有適當的保護，可能會允許濫用查詢
緩存策略可能比REST更復雜
❝
REST和GraphQL之間的最佳選擇取決於應用程式和開發團隊的具體要求。GraphQL非常適合復雜或頻繁變化的前端需求，而REST適合那些首選簡單和一致的合約的應用程式。
這兩種API方法都不是銀彈。仔細評估需求和權衡對於選擇正確的風格很重要。REST和GraphQL都是公開數據和支持現代應用程式的有效選擇。
gRPC是如何工作的？
RPC（Remote Procedure Call）被稱為「遠端」，因為它在微服務架構下，當服務部署到不同的伺服器時，可以實作遠端服務之間的通訊。從使用者的角度來看，它就像一個本地函式呼叫。
上圖說明了gRPC的總體數據流
步驟1 ：從客戶端進行REST呼叫。請求體通常是JSON格式。
步驟2 ~ 4 ：訂單服務（gRPC客戶端）接收REST呼叫，對其進行轉換，並對支付服務進行RPC呼叫。gRPC將客戶端存根編碼為二進制格式，並將其發送到低階傳輸層。
步驟5 ：gRPC透過HTTP 2在網路上發送封包。由於二進制編碼和網路最佳化，gRPC據說比JSON快5倍。
步驟6 - 8 ：支付服務（gRPC伺服器）從網路接收封包，對其進行解碼，並呼叫伺服器應用程式。
步驟9 - 11 ：結果從伺服器應用程式返回，並進行編碼並行送到傳輸層。
步驟12 - 14 ：訂單服務接收封包，對它們進行解碼，並將結果發送到客戶端應用程式。
什麽是Webhook？
下圖顯示了輪詢和Webhook之間的比較
假設我們執行一個電子商務網站。客戶端透過API閘道器將訂單發送到訂單服務，訂單服務轉到支付服務進行支付交易。然後，支付服務與外部支付服務提供商（PSP）進行通訊以完成交易。
❝
有兩種方法可以處理與外部PSP的通訊。
1.短輪詢
在向PSP發送支付請求之後，支付服務繼續詢問PSP關於支付狀態。經過幾輪之後，PSP最終返回狀態。
短輪詢有兩個缺點
續的狀態輪詢需要來自支付服務的資源。
外部服務直接與支付服務通訊，從而產生安全漏洞。
2.Webhook
我們可以使用外部服務註冊一個webhook。這意味著：當你有關於請求的更新時，請在某個URL上給我回電話。當PSP完成處理後，它將呼叫HTTP請求來更新支付狀態。
透過這種方式，改變了編程範例，並且支付服務不再需要浪費資源來輪詢支付狀態。
如果PSP不回電話怎麽辦？我們可以設定一個清潔工，每小時檢查一次付款情況。
❝
Webhook通常被稱為反向API或推播API，因為伺服器向客戶端發送HTTP請求。使用Webhook時需要註意三點：
我們需要設計一個合適的API供外部服務呼叫。
出於安全原因，我們需要在API閘道器中設定適當的規則。
我們需要在外部服務註冊正確的URL。
如何提高API效能？
下圖顯示了提高API效能的5個常用技巧
分頁
當結果的大小很大時，這是一種常見的最佳化。結果流回客戶端，以提高服務響應能力。
異步日誌記錄
同步日誌記錄處理每次呼叫的磁盤，可能會降低系統的速度。異步日誌記錄首先將日誌發送到無鎖緩沖區，然後立即返回。日誌將定期重新整理到磁盤。這大大降低了I/O開銷。
緩存
我們可以將頻繁存取的數據儲存到緩存中。客戶端可以先查詢該快取，而不是直接存取資料庫。如果存在緩存未命中，則客戶端可以從資料庫查詢。像Redis這樣的緩存將數據儲存在記憶體中，因此數據存取比資料庫快得多。
有效載荷壓縮
可以使用gzip等壓縮請求和響應，以便傳輸的數據大小要小得多。這加快了上傳和下載的速度。
連線池
在存取資源時，我們經常需要從資料庫中載入數據。開啟正在關閉的資料庫連線會增加大量開銷。所以我們應該透過一個開放連線池連線到資料庫。連線池負責管理連線生命周期。
如何設計安全有效的API？
❝
下圖以購物車為例展示了典型的API設計
請註意，API設計不僅僅是URL路徑設計。大多數時候，我們需要選擇適當的資源名稱、識別元和路徑模式。在API閘道器中設計適當的HTTP頭欄位或設計有效的速率限制規則同樣重要。
