當我們構建 Web 應用程式時，通常會有多個服務。在絕大多數情況下，它們由許多不同的 Web 服務一起工作組成。在這種類型的由多個服務組成的 Web 應用程式中，如何傳輸數據是每個開發人員需要考慮的問題。在解決這個問題時，兩種方法已成為主流：webhooks 和輪詢。每種方法都提供了一種從一個服務到另一個服務獲取和傳遞數據的獨特方式。選擇其中一種方法可能會對你的應用程式的效率、實時功能和整體用戶體驗產生重大影響。本文將比較 webhooks 和輪詢，分析每種方法的優缺點，並討論何時應使用哪種方法。 ## 什麼是輪詢？輪詢（通常稱為 API 輪詢）是指客戶端以固定的間隔時間（比方說，每 x 秒）請求特定數據，而伺服器則會以被請求的數據進行回應的過程。可以把它想像成定期詢問，“有新數據嗎？” 輪詢可以通過 HTTP 請求來實現，客戶端向伺服器發送 GET 請求，然後伺服器用所請求的數據回應。想像一下，John 建立了一個名叫 Doc.AI 的 AI 文件產品，並使用 Logto 進行用戶身份管理。 Frank 是使用 John 的產品並創建了自己個人賬戶的一位用戶。有一天，Frank 加入了他的朋友 David 創建的工作區。此時，John 想發電子郵件給 Frank，要求他在授予他訪問額外敏感資源的權限前開啟多重身份驗證 (MFA) 來增強賬戶安全性。 John 的產品後端需要不斷地輪詢相關 API 來知道 Frank 何時加入 David 的工作區。 ```mermaid sequenceDiagram participant Client as Doc.AI (server) participant Server as Logto loop Polling every x seconds Client->>Server: Send API request
"Frank 加入 David 的工作區了嗎？" Server-->>Client: 沒有 end note right of Client: Frank 加入了 David 的工作區 Client->>Server: Send API request
"Frank 加入 David 的工作區了嗎？" Server-->>Client: 是! note right of Client: Doc.AI 開始工作：
1. 發送電郵給 Frank
2. 等待 MFA 完成
... ``` ## 什麼是 webhook？ Webhook（即 "HTTP 回調"）是一種實時數據通信的機制，伺服器會在事件發生時將數據發送給客戶端。不同於客戶端請求數據，webhook 會在每次有更新時將數據推送給客戶端。可以把它想像成你的應用程式的收件箱。當某些事件發生時——例如，一個新用戶註冊或支付完成——webhook 會在收件箱中拋出一條消息，讓你的應用程式知道正在發生什麼事情。讓我們繼續使用之前用來解釋輪詢的 Doc.AI 示例。如果使用 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 可以實現實時數據同步，而這是輪詢無法實現的。 ## 我應該選哪一個？根據輪詢和 webhooks 的機制，一般的做法是當數據頻繁更新且對數據的實時性要求不嚴格時，才選擇使用輪詢。在其他情況下，webhooks 會是更好的選擇。然而，當選擇使用 webhooks 時，開發人員需要注意以下問題： 1. 如果系統對獲取的數據高度依賴，則需要考慮當 webhook 失敗且數據無法同步時，有一個備用方案來獲取數據，包括不限於輪詢或要求 webhook 具有重新發送機制等。 2. 在接收 webhooks 的客戶端端點中，應實施 API 秘密和內容簽名驗證等，以防止駭客通過偽造 webhook 來攻擊客戶端。 3. 由於 webhook 可能會發送重複的請求，此時需要做相應的處理以防止數據重複和不一致。 Logto 作為一個非常受歡迎的用戶識別解決方案，提供豐富的 webhook 場景和卓越的安全性。使用 Logto 作為你的產品的身份系統，它可以輕鬆地集成並適合各種應用場景。