六種主流 API 架構特性比較：依通訊模型與業務場景選擇合適架構。
API 架構矩陣圖
API 架構矩陣圖
API 選錯架構的代價很實際：頻寬塞爆、延遲拉高，後面接手維護的人大概每天都想提離職。主流的 REST、GraphQL、gRPC、WebSocket、SOAP、Webhook 各有各的死穴跟強項，這篇直接整理它們適用的場景與取捨。
01. 六種 API 架構的強項與限制
1. REST (Representational State Transfer)
最普及也最直觀的選擇。以 HTTP 方法（GET、POST、PUT、DELETE）為核心，把所有資料當成「資源」操作。
- 主要優點：
- 標準與普及度高：天生依附 HTTP 規範，全世界的工程師與工具（Postman、Swagger、瀏覽器）都原生支援。
- 無狀態性（Stateless）：伺服器無需保留對話 Session，方便做水平擴展。
- 內建生態快取：善用 HTTP Cache-Control、CDN 與反向代理，能輕易扛住重複讀取流量。
- 主要限制：
- Over-fetching 與 Under-fetching：端點回傳欄位固定，前端常拿到一堆用不到的資料（浪費流量），或必須打好幾隻 API 才能湊齊一個畫面。
- 即時性弱：本質上是「請求-回應」單向模型，無法勝任毫秒級即時通訊。
- 適合場景：公開對外 API、CRUD 形態為主的 Web 管理系統、微服務邊界閘道。
2. GraphQL
由 Facebook 開發的查詢語言。改由前端精確宣告自己需要哪些欄位，要什麼給什麼。
- 主要優點：
- 零過量抓取（No Over-fetching）：手機端只需載入 3 個欄位，回傳就只包含這 3 個欄位，節省行動端頻寬。
- 單一端點聚合：只需發送一次請求，即可透過關聯取得嵌套資料（例如：文章作者及其最新 5 篇評論）。
- 嚴格型別架構（Schema-Driven）：前後端共用強型別 Schema，代碼生成與除錯都很順暢。
- 主要限制：
- 後端解析複雜度高（N+1 難題）：若未妥善引入 DataLoader 機制，前端一次深層查詢可能直接拖垮資料庫。
- 缺乏原生 HTTP 快取：所有請求通常都走
POST /graphql，無法直接利用 CDN 或瀏覽器預設快取。
- 適合場景：儀表板後台、跨行動端（iOS/Android/Web）複雜前端應用、BFF（Backend for Frontend）層。
3. gRPC (Google Remote Procedure Call)
Google 主導的高效能 RPC 框架。基於 HTTP/2 傳輸，並採用二進位序列化的 Protocol Buffers (protobuf)。
- 主要優點：
- 極小封包與高效能：二進位壓縮比 JSON 小得多，序列化與反序列化速度快 7 到 10 倍。
- 多工串流支援：HTTP/2 單一 TCP 連線多工處理，原生支援客戶端串流、伺服器串流與雙向串流。
- 跨語言契約明確：透過
.proto定義檔，自動生成 Go、Java、Python、C# 等多語言的呼叫程式碼。
- 主要限制：
- 對 Web 瀏覽器不友善：瀏覽器無法直接原生發起 gRPC 請求，通常需要透過 gRPC-Web 或 API Gateway 轉譯。
- 二進位不直觀：無法直接用一般 curl 查看封包內容，除錯門檻較高。
- 適合場景：內部微服務之間的高頻通訊、低延遲運算節點、IoT 與邊緣裝置。
4. WebSocket
建立在單一 TCP 連線上的全雙工（Full-Duplex）長連接協議。客戶端與伺服器完成初始 HTTP 握手後，雙方可隨時主動推送訊息。
- 主要優點：
- 極低延遲：沒有 HTTP 每次請求反覆建立連線與標頭的開銷，訊息毫秒級到達。
- 雙向主動推播：伺服器有事件時可立刻推給客戶端，不用反覆輪詢（Polling）。
- 主要限制：
- 伺服器長連線負載：同時維持大量連線對伺服器記憶體與連線數上限有要求。
- 架構較複雜：需要處理心跳機制（Heartbeat）、斷線重連、多節點廣播（需搭配 Redis Pub/Sub 等）。
- 適合場景：線上即時聊天、金融即時報價、協同編輯畫布、多人連線遊戲。
5. SOAP (Simple Object Access Protocol)
以嚴謹、安全著稱的企業級協議。完全基於 XML 規格與 WSDL 合約。
- 主要優點：
- 高安全性標準（WS-Security）：原生支援傳輸層與訊息層加密、身分驗證與簽章。
- 強大的交易完整性（ACID / WS-ReliableMessaging）：保證訊息一定送達且只執行一次（Exactly-once）。
- 主要限制：
- 繁複冗長：XML 標頭龐大，傳輸效率低，除錯排查非常痛苦。
- 架構僵化：規範繁複嚴格，很難快速變更迭代。
- 適合場景：金融金流清算、銀行核心系統介接、大型政府機關與醫療企業系統。
6. Webhook
反向 API（Reverse API）。不同於傳統「你問我答」，而是當事件觸發時，由伺服器主動打 HTTP POST 到你預先註冊的 Callback URL。
- 主要優點：
- 完全非同步、省資源：平常零連線開銷，有事件才通知，省去無效輪詢。
- 對接門檻低：接收端只需要開出一隻標準的 HTTP POST 端點即可完成介接。
- 主要限制：
- 無法保證即時送達：若接收端伺服器短暫異常或逾時，可能遺漏訊息（需要發送端有重試機制）。
- 需注意安全驗證：接收端務必驗證 HMAC 簽名與冪等性（Idempotency），避免重送攻擊。
- 適合場景：第三方金流支付結果回告（Stripe / 綠界）、CI/CD Pipeline 自動化觸發（GitHub Push）、SaaS 事件通知。
02. 六大架構多維度對照表
把這幾種架構放在一起看，差異會更清楚：
| 架構類型 | 傳輸協議 | 資料格式 | 通訊模式 | 傳輸效能 | 最核心適用情境 |
|---|---|---|---|---|---|
| REST | HTTP 1.1 / 2 | JSON / XML | 請求 – 回應 | 中等 | 標準 Web 服務、對外公開 API、CRUD 系統 |
| GraphQL | HTTP 1.1 / 2 | JSON | 請求 – 回應 | 中等至優 | 多端複雜前端、數據聚合層、BFF 架構 |
| gRPC | HTTP/2 | 二進位 (Protobuf) | 多工雙向串流 | 極高 | 內部微服務高頻通訊、低延遲高效能系統 |
| WebSocket | TCP (WS/WSS) | 自訂文字 / 二進位 | 全雙工長連接 | 極高 | 即時通訊軟體、協同畫布、即時看板、線上遊戲 |
| SOAP | HTTP / SMTP | XML | 請求 – 回應 | 較低 | 銀行金融清算、醫療體系、企業合約系統 |
| Webhook | HTTP POST | JSON / Form | 非同步事件推播 | 優（按需觸發） | 第三方金流回告、SaaS 事件訂閱、Git 觸發 |
03. 怎麼選？實戰決策路徑
選型的時候先想清楚最關鍵的需求：
🎯 快速選型速查
- 👉 要做標準公開 API、給第三方串接？ → 選 REST。生態最完整，相容性最高。
- 👉 前端介面複雜，欄位常變，手機端流量很貴？ → 選 GraphQL。
- 👉 微服務內部呼叫頻繁，極度要求吞吐量與低延遲？ → 選 gRPC。
- 👉 需要即時雙向互動、推送股票跳動或聊天訊息？ → 選 WebSocket。
- 👉 需要等第三方系統處理完成後非同步通知我們？ → 選 Webhook。
- 👉 在傳統金融、保險或大型跨國企業有強制 XML/合約安全審查？ → 選 SOAP。
在實際專案裡，通常不會只選一種：對外開 REST 或 GraphQL 給前端，內部微服務通訊跑 gRPC 搶延遲，需要推播掛 WebSocket，第三方通知走 Webhook。不用硬要一套打天下，混著用把各家長處發揮出來才是常態。
