Skip to main content
繁體中文

Webhook 與 API 輪詢用於 WiFi 資料：該選擇哪一種？

本指南針對擷取 WiFi 智慧資料的 webhook 與 API 輪詢，提供了明確的技術比較。它為 IT 經理、架構師和開發人員提供了可操作的指導，協助他們選擇最佳的資料整合模式，以實現企業環境中的即時回應能力、營運效率和可擴充部署。

📖 9 min read📝 2,108 words🔧 2 worked examples❓ 3 practice questions📚 8 key definitions

Listen to this guide

View podcast transcript
歡迎收聽 Purple 技術簡報。我是主持人，也是 Purple 的資深技術策略師。今天，我們將探討 IT 領導者和開發人員在將 WiFi 智慧整合到業務營運中時面臨的一項關鍵決策：您應該使用 webhook 還是 API 輪詢來擷取資料？這項選擇對系統的效率、即時能力和總擁有成本有重大影響。 作為背景，像 Purple 這樣的平台能從您的訪客 WiFi 網路中解鎖大量資料——誰在連線、他們在哪裡、連線多久等等。挑戰在於如何將這些有價值的資料以及時且有效率的方式，傳送到您的其他系統，例如 CRM、行銷自動化平台或商業智慧工具。這就是 webhook 與 API 輪詢之爭的開端。 我們從傳統方法：API 輪詢開始。想像您正在長途開車旅行，後座的孩子每隔五秒就問一次：「我們到了嗎？」這基本上就是 API 輪詢。您的應用程式（客戶端）以固定間隔，重複向 Purple API 發送 HTTP 請求，詢問：「有沒有新資料？」大多數時候，答案都是「沒有，沒有新的。」這設定起來很簡單；一個基本的腳本就能做到。系統的負載是可預測的。然而，缺點卻相當顯著。它極度沒效率。您發出的數百或數千次請求都是空白的，消耗了兩端的頻寬和伺服器資源。更重要的是，您的資料永遠不是真正的即時。如果您每分鐘輪詢一次，您的資料可能已過時長達 59 秒。在追求即時顧客互動的世界裡，這猶如一生之久。 現在，讓我們來看看現代的事件驅動方法：webhook。將 webhook 想像成門鈴。您不會站在門邊，每隔 10 秒就開門看看是否有訪客。您會等待鈴聲響起。當鈴聲響起，您就知道有人來了，然後採取行動。Webhook 的運作方式完全相同。您提供一個 URL——您的 webhook 端點——給 Purple 平台。當特定事件發生時，例如賓客連接到 WiFi，我們的平台會立即發送一則通知，一個小小的資料包或「酬載」，直接送到您的 URL。您的系統接著接收這些資料，並可立即觸發工作流程。 這本質上是一種更有效率且更強大的模型。資料在事件發生的當下即時傳遞。您的伺服器無需負擔不斷發出徒勞請求的重擔；它僅在確實有資料需要處理時才進行處理。這是一種高度可擴充的架構，可降低伺服器負載並提高吞吐量。初始設定稍微複雜一些，因為您需要在伺服器上建立一個穩定、可公開存取的端點，來監聽這些傳入的酬載。但其投資回報是巨大的，特別是對於時間敏感的應用程式。 那麼，讓我們直接比較兩者。就資料新鮮度而言，webhook 提供即時傳遞，而輪詢則總是受限於輪詢間隔而延遲。就效率而言，webhook 非常高效，僅在有新資料時才進行通訊，而輪詢則因大量空白請求而本質上沒有效率。這直接影響伺服器負載：webhook 負載低，輪詢則負載高且持續。輪詢的初始實作看似較簡單，但長期的營運成本和效能限制，使得 webhook 成為了幾乎所有現代使用案例的更佳選擇。 那麼，何時該使用每種模式呢？對於非關鍵的、批次導向的任務，您可能仍會使用 API 輪詢。例如，為夜間報表拉取匯總分析資料，數分鐘或一小時的延遲是完全可接受的。如果您的基礎架構基於安全或政策原因，絕對無法暴露公開端點來接收 webhook 呼叫，這也是一種備援方案。 然而，對於任何受益於即時性的流程，webhook 就是明確的答案。讓我們看看一些真實世界的部署案例。一家大型連鎖飯店使用 Purple 的 webhook，在賓客登入 WiFi 的當下，觸發一封帶有個人化客房服務優惠的「歡迎」電子郵件。這是輪詢永遠無法實現的即時、情境化互動。一家大型零售集團使用 webhook，每當 VIP 客戶進入商店並連接到網路時，便透過行動應用程式提醒其店內忠誠度團隊。這實現了高接觸度的個人化服務，從而提升忠誠度。在會議中心，webhook 被用來即時監控 WiFi 使用情況。若特定區域超過一定的裝置密度，就會向營運團隊發送警報，以管理人潮流動或調整空調。這是由即時資料驅動的主動式場地管理。 在實作 webhook 時，有一些最佳實務需要遵循。首先，保護您的端點。始終使用 HTTPS。其次，您必須驗證傳入的酬載，以確保它們確實來自 Purple。我們的平台在請求標頭中包含一個唯一的簽章，您可以使用共用密鑰進行驗證。這可以防止詐騙並確保資料完整性，是遵循 GDPR 等標準的關鍵步驟。第三，使您的端點具有復原能力。它應快速回應以確認收到資料，然後在背景佇列中非同步處理資料。這可以防止逾時，並確保在活動突然激增時不會錯過事件。 現在進行快速問答環節。一個常見問題是：「我不能就把輪詢間隔設為一秒嗎？」您可以試試看，但很可能會因請求過多而遭到 API 速率限制。這是一種效率不佳的反模式，且仍然無法保證真正的即時資料。另一個問題：「如果我的端點中斷了呢？」像 Purple 這樣專業級的 webhook 系統具有重試機制。如果您的端點未回應成功代碼，我們將在一段時間內嘗試數次重新發送事件，讓您的系統有時間恢復。 總而言之，雖然 API 輪詢在簡單、非緊急的批次任務中仍有其地位，但 webhook 是將即時 WiFi 資料整合到業務工作流程中的更佳、專業的標準。它們更有效率、更具擴充性，並能實現定義現代客戶體驗和智慧場館營運的即時、事件驅動行動。如果您想觸發行銷訊息、警示員工，或饋送即時安全儀表板，您就需要 webhook 的即時能力。 要開始使用，請造訪 Purple 入口網站的開發者專區。在那裡，您可以找到有關我們 webhook 事件、酬載結構的詳細文件，以及設定第一個端點的逐步指南。感謝您收聽本次 Purple 技術簡報。我們期待協助您充分發揮 WiFi 資料的全部潛力。

header_image.png

執行摘要

對於 IT 領導者和場地運營商而言，選擇從 Purple 這類 WiFi 智慧平台擷取資料的方法是一項基礎架構決策，會帶來重大的營運後果。兩種主要模式——API 輪詢和 webhook，在實作簡易性與即時效能之間提供了明顯的取捨。API 輪詢是一種由客戶端啟動的拉取模型，會以固定間隔重複查詢 API 以取得新資料。雖然部署簡單，但會耗費大量資源，產生固有的資料延遲，且擴充性不佳。相對地，webhook 採用由伺服器啟動、事件驅動的推送模型。當特定事件發生時（例如訪客連接到網路），它們會立即將資料酬載傳遞至預先定義的端點。這種方法提供真正的即時資料，確保高資源效率，並提供優異的擴充性。對於任何需要立即、情境化參與的應用程式——從觸發行銷自動化到發送營運警報——webhook 是架構上更好的選擇。本指南對兩種模式進行技術深入探討，提供廠商中立實作指導，並呈現真實案例研究，協助架構師和開發人員做出符合其業務目標（包括 ROI、吞吐量和風險降低）的明智決策。

技術深入探討

了解 API 輪詢和 webhook 之間的基本差異，對於設計能善用 WiFi 資料的穩固且高效率系統至關重要。本節將探討每種模式的架構、效能特性和安全考量。

什麼是 API 輪詢？

API 輪詢是一種同步的、基於拉取的機制，客戶端應用程式以預定的頻率向伺服器 API 重複發出 HTTP 請求，以檢查是否有新資料。其運作基於簡單的請求-回應循環：客戶端詢問「有沒有新資訊？」，伺服器則做出回應。

特徵：

  • 由客戶端啟動： 客戶端負責啟動所有通訊。
  • 固定間隔： 請求以固定間隔（例如每 60 秒）發出。
  • 同步： 在繼續進行或發出下一個請求之前，客戶端會等待回應。

優點：

  • 簡單性： 實作通常很直接，只需一個簡單的腳本或排程任務來發出 HTTP GET 請求。
  • 可預測的負載： 客戶端系統的負載一致且易於預測。

缺點：

  • 效率不佳： 絕大多數的輪詢不會回傳新資料，消耗了客戶端和伺服器兩端不必要的頻寬和處理週期。在大規模部署中，這是相當浪費的來源。
  • 延遲： 資料永遠不是真正的即時。資料的「新鮮度」充其量受限於輪詢間隔。若間隔為 5 分鐘，資料可能已過時長達 4 分 59 秒，這對於對時間敏感的應用程式是無法接受的。
  • 擴充性問題： 隨著客戶端數量或輪詢頻率增加，伺服器 API 的負載呈線性成長，可能導致效能下降或觸發速率限制。

什麼是 Webhook？

Webhook 是一種非同步的、基於推送的伺服器對伺服器通訊機制。伺服器不會讓客戶端重複要求資料，而是在特定事件發生時，自動將資料酬載傳送（或推送）至指定的客戶端 URL（「webhook 端點」）。這通常被稱為「反向 API」或事件驅動架構。

特徵：

  • 由伺服器啟動（事件驅動）： 通訊由伺服器上的事件觸發（例如 guest_connects、user_leaves_venue）。
  • 即時： 資料在事件發生時幾乎立即傳遞。
  • 非同步： 客戶端被動接收資料，無需主動發起請求。

webhook_vs_polling_comparison.png

優點：

  • 效率： 僅在有新資料要分享時才進行通訊，避免了浪費的請求，並大幅降低伺服器和網路負載。
  • 即時資料： Webhook 是實現即時資料傳遞的業界標準，可實現即時行動和情境化工作流程。
  • 擴充性： 此架構具有高度擴充性，因為伺服器僅在事件觸發時耗費資源，而非持續處理來自數千個客戶端的輪詢。

缺點：

  • 實作複雜性： 初始設定較為複雜。需要在客戶端建立一個穩定、可公開存取的 HTTP 端點，以接收來自伺服器的傳入 POST 請求。
  • 可靠性管理： 客戶端應用程式必須設計為能可靠處理傳入資料，包括管理可能的停機時間和處理量激增。

架構比較

特點 API 輪詢 Webhook（事件驅動）
資料流 拉取（客戶端啟動） 推送（伺服器啟動）
資料新鮮度 延遲（受限於輪詢間隔） 即時
效率 低（許多空請求） 高（僅在事件發生時通訊）
伺服器負載 高且持續 低且零星（事件時）
客戶端負載 高（持續請求） 低（被動監聽）
擴充性 差 優異
實作 初始設定簡單 需要公開端點

安全考量

兩種模式都需要健全的安全措施，尤其是在處理受到如 GDPR 等法規管轄的個人識別資訊（PII）時。[1]

  • 針對 Webhook： 安全性至關重要。接收端點必須使用 HTTPS（TLS 加密）加以保護，以確保傳輸中的資料安全。此外，為防止惡意行為者向您的端點發送偽造資料的詐騙攻擊，必須驗證酬載。Purple 平台遵循業界最佳實務，在每個 webhook 請求的 X-Purple-Signature HTTP 標頭中包含一個唯一的簽章。此簽章是酬載主體的雜湊值（HMAC-SHA256），使用您應用程式與 Purple 之間共用的密鑰產生。您的端點必須計算相同的雜湊值，並在處理資料前驗證其是否與標頭中的簽章相符。這可確保資料是真實的（來自 Purple）且未遭到篡改。

  • 針對 API 輪詢： 主要的安全考量是 API 金鑰的管理。此金鑰必須安全儲存，且絕不應暴露在客戶端程式碼中。所有 API 通訊也必須透過 HTTPS 進行。應記錄和監控存取，以偵測可能表明金鑰已遭洩漏的異常活動。

實作指南

選擇正確的模式完全取決於整合的業務需求。在複雜的企業架構中，混合方法很常見。

architecture_overview.png

何時使用 API 輪詢

儘管效率不佳，API 輪詢對於特定的非關鍵用途仍是一個可行的選擇：

  • 批次報告： 產生關於整體 WiFi 使用量的夜間或週報告，其中資料延遲數小時是可接受的。
  • 內部儀表板： 將趨勢資料填入非關鍵的內部儀表板，無需精確到秒的準確度。
  • 傳統系統： 與無法暴露公開端點來接收 webhook 的舊系統整合。
  • 基礎架構限制： 在高安全性環境中，根據政策，來自外部服務的傳入流量受到嚴格限制。

何時使用 Webhook

對於任何現代的即時應用程式，Webhook 都是明確的選擇。每當對 WiFi 事件的立即、自動化回應能創造業務價值時，就應使用它們。

  • 即時行銷： 當訪客在飯店或零售商店連接到 WiFi 時，立即觸發歡迎電子郵件、附有優惠券的簡訊，或向忠誠度應用程式發送推播通知。
  • 營運警報： 當特定事件發生時，例如 VIP 訪客抵達、特定區域的停留時間超過閾值，或網路硬體離線，透過 Slack 或專用應用程式向員工發送即時警報。
  • CRM 整合： 當新訪客在 Captive Portal 上註冊時，立即在 Salesforce 或 HubSpot 等 CRM 中建立或更新客戶記錄。
  • 場地營運： 使用即時裝置密度資料來管理體育場的人潮動線、調整會議中心的 HVAC，或派遣清潔人員到高人流量區域。

實作 Purple 的 Webhook：概念性指南

  1. 建立您的端點： 在您的伺服器上開發一個穩定、公開的 URL，可接受 HTTP POST 請求。這可以是無伺服器函式（例如 AWS Lambda、Google Cloud Function），或是網頁應用程式中的專用路由。
  2. 在 Purple 中註冊端點： 在 Purple 入口網站中，導航至 webhook 區塊並新增您的端點 URL。您將獲得用於簽章驗證的密鑰。
  3. 處理傳入資料： 當事件發生時，Purple 會將 JSON 酬載傳送至您的端點。您的端點應設計為： a. 立即確認接收： 儘速回應 200 OK 狀態碼，讓 Purple 知道資料已接收。這可防止逾時和重試。 b. 驗證簽章： 處理前，使用您的密鑰計算原始請求主體的 HMAC-SHA256 簽章，並將其與 X-Purple-Signature 標頭中的值進行比較。若不符，則捨棄該請求。 c. 非同步處理： 將實際的業務邏輯（例如發送電子郵件、更新資料庫）卸載到背景作業佇列（例如 RabbitMQ、Redis Queue）。這可確保您的端點保持回應能力，並能處理大量事件而不會受阻。

最佳實務

遵循業界標準最佳實務對於建立可靠且安全的整合至關重要。

Webhook 最佳實務

  • 冪等性： 設計您的處理邏輯，使其能妥善處理重複事件。網路問題有時會導致同一 webhook 被傳遞多次。冪等系統可確保多次處理相同事件不會導致重複的資料或操作。
  • 非同步處理： 切勿直接在請求處理程序中執行複雜或耗時的邏輯。先確認接收並放入佇列。
  • 酬載驗證： 務必驗證 webhook 簽章。這是關鍵的安全步驟。
  • 監控與記錄： 實作全面的記錄功能，以追蹤傳入的 webhook 及其處理結果。設定監控，當您的端點故障或回應時間變慢時發出警報。
  • 優雅失敗與重試： 儘管 Purple 的系統包含重試機制，您自己的系統應對下游服務（例如資料庫或第三方 API 暫時無法使用）的失敗具有復原能力。

API 輪詢最佳實務

  • 選擇適當的頻率： 不要以高於必要的頻率進行輪詢。過度輪詢不僅收益遞減，還會增加被速率限制的風險。若收到 429 Too Many Requests 回應，請遵守 Retry-After 標頭。
  • 使用條件式請求： 在支援的情況下，使用如 If-Modified-Since 或 ETag 等標頭，避免重新下載未變更的資料。
  • 實作退避策略： 若 API 呼叫失敗，請對重試實作指數退避策略，以避免壓垮伺服器。
  • 保護 API 金鑰： 使用密鑰管理服務安全地儲存 API 金鑰。切勿在應用程式中hard-code，或將其提交至版本控制系統。

疑難排解與風險緩解

  • 常見故障模式 (Webhook)：端點停機。 若您的端點中斷，您將錯過事件。緩解措施： 為您的端點使用高可用性架構（例如無伺服器函式、負載平衡伺服器）。對於短暫中斷，仰賴 Purple 內建的重試機制，並實作健全的監控功能，以便立即收到停機警報。
  • 常見故障模式 (Webhook)：處理量激增。 突然的事件爆發（例如活動開始時大量人群連線）可能使您的處理佇列不堪負荷。緩解措施： 確保您的背景處理基礎架構能夠自動擴充，以因應需求激增。
  • 常見故障模式 (API 輪詢)：速率限制。 過度的輪詢將導致您的應用程式被速率限制，從而有效地切斷資料流。緩解措施： 以合理且得當的間隔進行輪詢，並實作指數退避策略。
  • 常見故障模式 (兩者)：資料無效。 資料格式變更或非預期的值可能破壞您的處理邏輯。緩解措施： 實作防禦性程式設計實務。依據結構描述驗證傳入資料，並妥善處理驗證錯誤，記錄下來以供調查，而不致使整個程序崩潰。

ROI 與業務影響

Webhook 與輪詢之間的選擇對總擁有成本（TCO）和投資回報率（ROI）有直接影響。

  • 成本效益分析： 雖然輪詢的初始開發成本可能略低，但其營運成本因浪費的伺服器資源和頻寬而顯著較高。Webhook 憑藉其事件驅動的效率，在大規模營運時可導致遠較低的 TCO。處理每日數百萬次空輪詢的基礎架構成本，遠超過開發可靠 webhook 端點的成本。
  • 衡量成功： 即時資料整合的成功與否由其業務影響來衡量。對於飯店，這可能是由 webhook 觸發的迎賓優惠所帶動的客房服務訂單增加 15%。對於零售商，可能是因獲得個人化店內服務的 VIP 客戶終身價值有可衡量的提升。對於場地，可能是因主動式人群管理而減少的營運事件。
  • 預期成果： 部署基於 webhook 的架構，能使您的組織更加靈活且反應迅速。它將您的營運從被動姿態（分析昨天發生的事）轉變為主動、即時的姿態（對當下正在發生的事採取行動）。這項能力是提供優異客戶體驗和實現卓越營運的關鍵差異化因素。

參考文獻

[1] General Data Protection Regulation (GDPR). (2016). Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2016/679/oj

Key Definitions

Webhook

一種實現伺服器對伺服器即時通訊的機制。它允許伺服器在事件發生時，自動將資料推送給客戶端，而不需客戶端重複輪詢。

IT 團隊使用 webhook 從 Purple 等平台接收即時通知，實現事件驅動的工作流程，例如在賓客連接到 WiFi 時立即發送歡迎電子郵件。

API 輪詢

一種資料擷取方法，客戶端應用程式以固定間隔向伺服器發出請求，以檢查是否有新資料。這是一種由客戶端啟動的「拉取」模型。

開發人員可能使用 API 輪詢，每 15 分鐘以新的 WiFi 分析資料更新內部儀表板，此時即時資料並非關鍵的業務需求。

端點

客戶端伺服器上的一個公開可存取的 URL，設計用於接收和處理來自 webhook 的傳入資料。

在 Purple 中設定 webhook 時，網路架構師必須提供穩定且安全的端點 URL，讓平台發送事件資料。

酬載

當事件觸發時，從伺服器傳送到 webhook 端點的實際資料，通常為 JSON 格式。

對於 `guest_connects` 事件，酬載將包含有關賓客、其裝置和位置的資訊，行銷自動化工具隨後可使用這些資訊進行個人化。

冪等性

運算中的一項原則，即一個操作若執行多次，其效果與僅執行一次相同。在 webhook 的情境中，這意味著處理重複事件不會導致重複結果。

為了達到冪等性，開發人員確保其端點在採取行動前，檢查事件 ID 是否已處理過，避免單一 WiFi 連線觸發兩封歡迎電子郵件。

非同步處理

一種處理模型，其中任務在背景中執行，與應用程式主執行緒分開。對於 webhook，這意味著立即確認請求，然後在獨立的佇列中處理酬載。

IT 團隊實作非同步處理，以確保其 webhook 端點能在體育場演唱會期間，處理數千個同時發生的 WiFi 連線事件而不逾時。

HMAC（雜湊式訊息鑑別碼）

一種使用密鑰來驗證訊息資料完整性和真實性的密碼雜湊。

為了符合 PCI DSS 等資料安全標準，網路架構師必須確保其 webhook 端點驗證所有傳入酬載的 HMAC 簽章，以防止詐騙性資料注入。

速率限制

一種 API 管理技術，用於控制伺服器的傳入流量。若客戶端在指定時間範圍內超過一定數量的請求，伺服器將暫時封鎖他們。

一位營運總監發現其每小時分析報告失敗，原因是其過度積極的 API 輪詢策略導致 Purple 平台執行了速率限制。他們必須將輪詢間隔調低頻率。

Worked Examples

一間擁有 500 間客房的機場飯店，希望能在賓客首次連結飯店 WiFi 時，自動發送一封附有餐廳優惠券的歡迎電子郵件。目標是促使當天晚餐預訂。該飯店使用 Salesforce Marketing Cloud。

這是一個典型的即時互動情境，使得 webhook 成為唯一可行的解決方案。

  1. 在 Salesforce 中建立 Journey API 端點： 在 Salesforce Marketing Cloud 中，建立一個以 API 事件作為進入來源的新 Journey。這將提供一個唯一的 URL 和 API 金鑰，可以接收傳入事件。
  2. 在 Purple 中設定 Webhook： 在 Purple 入口網站中，為 guest_connects 事件建立一個新的 webhook。將 Salesforce Journey URL 貼上作為目的地。
  3. 設定酬載格式： 設定 webhook 酬載，以 Salesforce Journey API 預期的 JSON 格式，傳送必要的賓客資料（例如 first_name、email、location）。
  4. 保護 Webhook： 確保端點 URL 使用 HTTPS。雖然 Salesforce 的端點本質上是安全的，但若可能，將 Purple webhook 密鑰新增至 Salesforce 設定中以進行簽章驗證，或建立一個輕量級中介層（例如 AWS Lambda 函式）在將請求轉送至 Salesforce 前執行驗證，這一點至關重要。
  5. 啟用 Journey： 一旦成功接收測試事件，便啟用 Salesforce 中的 Journey。現在，當賓客連接到 WiFi 時，Purple 會立即觸發 webhook，將賓客注入 Salesforce Journey，後者隨即發送個人化的歡迎電子郵件。
Examiner's Commentary: 這是事件驅動架構的絕佳應用。在此處使用 API 輪詢根本行不通；5 分鐘的延遲將意味著賓客已到達房間並做了其他安排，完全錯失了提供情境化優惠的時機。Webhook 提供了影響賓客當下決策所需的即時性。使用專用中介層進行簽章驗證，是在目標系統未原生支援此功能時增強安全性的最佳實務建議。

一家擁有 200 間門市的連鎖零售業者，需要為每間門市填補中央分析儀表板的每小時人流資料。該儀表板由企業策略團隊用於分析數週乃至數月的趨勢。即時資料並非必要條件。

在此情境下，需求是定期的、匯總的資料，而非即時事件。因此，API 輪詢是合適且務實的選擇。

  1. 找出正確的 API 端點： 使用 Purple API 文件，找到提供歷史位置分析資料的端點，可依場地和時間範圍進行篩選。
  2. 開發輪詢腳本： 建立一個伺服器端腳本（例如在 cron job 上執行的 Python 腳本），每小時執行一次。
  3. 實作輪詢邏輯： 腳本會遍歷 200 個門市 ID 的清單。對於每間門市，它會向分析 API 端點發出 HTTP GET 請求，要求前 60 分鐘的訪客數。
  4. 儲存資料： 然後腳本會解析 JSON 回應，並將匯總資料（時間戳、門市 ID、訪客數）寫入支援儀表板的中央分析資料庫。
  5. 處理錯誤與重試： 腳本必須包含對 API 失敗或網路問題的錯誤處理，在重試失敗的請求時，實作指數退避策略，以免壓垮 API。
Examiner's Commentary: 這是 API 輪詢正確且有效率的使用方式。在此處使用 webhook 會過於複雜且不必要。Webhook 會針對每一次裝置連線觸發，將產生大量的事件，而後又需將其再匯總為每小時的計數。這將是資源的低效利用。每小時輪詢一次批次匯總資料，是更簡潔、更直接的解決方案，完全符合非即時趨勢分析的業務需求。它將 API 呼叫數降至最低，並簡化了資料處理管道。

Practice Questions

Q1. 一家大型購物中心希望在中庭的公共儀表板上，顯示已連線裝置數量的即時計數器。顯示內容需要盡可能準確地更新。開發團隊應使用哪種整合模式，原因為何？

Hint: 思考對「即時」和「準確」資料的需求。對延遲的容忍度為何？

View model answer

團隊必須使用 webhook。對「即時」計數器的需求意味著資料延遲是關鍵因素。用於 device_connected 和 device_disconnected 事件的 webhook，將使儀表板能夠真正即時地增加和減少計數器。使用 API 輪詢則會導致計數器僅定期更新（例如每分鐘），這感覺不像「即時」，且可能與實際的人潮流動明顯不同步。

Q2. 一位 IT 合規主管需要產生一份季度報告，詳細說明組織 50 個據點所使用的所有 WiFi 驗證方法，以確保符合 IEEE 802.1X 標準。該報告由分析師手動產生。應使用哪種模式來收集此資料？

Hint: 關注任務的時間敏感性。這是營運任務還是分析任務？

View model answer

API 輪詢是最合適的模式。此任務是分析性的，而非營運性的，且時間敏感性非常低（每季一次）。可以每季執行一次腳本，輪詢 Purple API 以取得過去 90 天內的所有驗證事件。這是為一次性分析收集大量歷史資料的簡單且有效率的方法。使用 webhook 並不適當，因為這需要儲存數百萬個即時事件長達數月，對於此需求而言過於複雜。

Q3. 體育場的行動應用程式有一項功能，允許球迷直接訂購食物送至座位。營運團隊希望使用 WiFi 位置資料，針對坐在餐飲服務已達容量的區域之球迷，停用此功能。停用該區的決策必須立即做出。在設計整合時，開發人員必須實作的最關鍵安全實務是什麼？

Hint: 該系統涉及基於傳入資料的即時營運控制。對這種系統的主要威脅是什麼？

View model answer

最關鍵的安全實務是對 webhook 端點執行強制性簽章驗證。由於 webhook 會觸發直接的營運行動（停用服務），因此該系統是詐騙攻擊的主要目標。惡意行為者可以向端點發送詐騙性的 webhook 酬載，偽裝成來自 Purple，並關閉整個體育場的訂購服務。透過使用共用密鑰驗證 X-Purple-Signature，端點可以在採取行動前，保證請求是真實的且其資料可信賴。雖然 HTTPS 和非同步處理也很重要，但簽章驗證是在此即時營運情境中，防禦資料驅動攻擊的關鍵。