當我們構建 Web 應用程序時，我們經常擁有多個服務。在絕大多數情況下，它們由許多不同的 Web 服務一起工作組成。在這種由多個服務組成的 Web 應用程序中，如何傳輸數據是每個開發者都需要考慮的問題。在解決這個問題時，兩種方法已成為主流：webhook 和輪詢。每種方法都提供了一種從一個服務到另一個服務抓取和傳送數據的獨特方式。選擇其中一種而非另一種可能會對你的應用程序效率、實時能力和整體用戶體驗產生重大影響。本文將比較 webhook 和輪詢，分析每種方法的優缺點，並討論何時應該使用哪一種。 ## 什麼是輪詢？輪詢（通常稱為 API 輪詢）是一個過程，其中客戶端以定期的間隔（比如，每個 x 秒）請求特定數據，然後服務器回應請求的數據。可以將其想像為定期問：“有新數據嗎？” 輪詢可以通過 HTTP 請求實現，客戶端向服務器發送 GET 請求，服務器則回應請求的數據。想像一下，John 建立了一個名為 Doc.AI 的 AI 文檔產品並使用 Logto 進行用戶身份管理。 Frank 是一個註冊了 John 的產品的用戶，並創建了他自己的個人帳戶。某天，Frank 加入了他的朋友 David 創建的工作空間。此時，John 想給 Frank 發電子郵件要求他開啟多因素認證（MFA）以增強他的帳戶安全性，然後再讓 Frank 獲取其他敏感資源的訪問權限。 John 的產品後端需要不斷地向相關 API 進行輪詢以知曉 Frank 加入了 David 的工作空間。 ```mermaid sequenceDiagram participant Client as Doc.AI (server) participant Server as Logto loop 每 x 秒輪詢一次 Client->>Server: 發送 API 請求
“Frank 加入了 David 的工作空間嗎？” Server-->>Client: 沒有 end note right of Client: Frank 加入了 David 的工作空間 Client->>Server: 發送 API 請求
“Frank 加入了 David 的工作空間嗎？” Server-->>Client: 是的！ note right of Client: Doc.AI 開始工作:
1. 發送電子郵件給 Frank
2. 等待 MFA 完成
... ``` ## 什麼是 webhook？ Webhook（即“HTTP 回調”）是一種實時數據通信的機制，當事件發生時，服務器會將數據發送到客戶端。與客戶端請求數據不同，webhook 每次有更新時會將其推送給客戶端。可以將其想像為應用程序的收件箱。當某些事件發生時——例如新用戶註冊或付款完成——webhook 會向收件箱投遞一條消息以告知應用程序發生了什麼。讓我們繼續用我們先前用於解釋輪詢的 Doc.AI 示例來說明 webhook。如果我們使用 webhooks 來了解 Frank 是否加入了 David 的工作空間，序列圖將如下所示： ```mermaid sequenceDiagram participant Client as Doc.AI (server) participant Server as Logto note right of Client: 其他 HTTP 請求 ... note right of Client: ... note right of Client: Frank 加入了 David 的工作空間 Server->>Client: 事件觸發的 webhook
“Frank 加入了 David 的工作空間” note right of Client: Doc.AI 開始工作:
1. 發送電子郵件給 Frank
2. 等待 MFA 完成
... ``` ## 重要的差異 - 請求來源輪詢是由客戶端初始化的（在我們的示例中，Doc.AI 是客戶端，Logto 是服務器），而 webhook 是由事件觸發，並由服務器啟動。 - 資源消耗輪詢會浪費計算資源，因為它以固定間隔發送請求，導致計算資源效率低下。而 webhook 是由服務器“按需”發起的。與輪詢相比，客戶端和服務器消耗的資源都少得多。 - 時間控制輪詢是客戶端啟動，因此客戶端可以控制數據獲取的時間；然而，webhook 是服務器啟動的，客戶端只能接收和處理數據。然而，由於兩者機制不同，webhook 可以實現實時數據同步，而這是輪詢無法實現的。 ## 我應該選哪一種？根據輪詢和 webhook 的機制，常見做法是當數據頻繁更新且對數據的實時性要求不嚴格時選擇輪詢。在其他情況下，webhook 會是更好的選擇。然而，選擇使用 webhook 時，開發者需要注意以下問題： 1. 如果系統非常依賴獲取的數據，需要考慮在 webhook 失敗且數據無法同步時有備份方案以獲取數據，包括但不限於輪詢或要求 webhook 具備重發機制等。 2. 在客戶端接收 webhook 的端點上，應應用 API 密鑰和內容簽名驗證等措施以防止黑客通過偽造 webhook 攻擊客戶端。 3. 由於 webhook 可能發送重複的請求，此時需要相應處理以防止數據重複和不一致。作為極受歡迎的用戶識別解決方案，Logto 提供了豐富的 webhook 場景和出色的安全性。使用 Logto 作為你產品的身份系統，能夠輕鬆整合並適應多種應用場景。