想像一下你正在緊盯一場關鍵運動賽事的最新比分：一種方式是你手動每隔幾秒就按一次瀏覽器的 F5 重新整理網頁，看看比分刷新了沒有；另一種方式是直接打開現場語音即時廣播，球員每次得分的瞬間，聲音毫無延遲地直接傳遞到你的耳機裡。
這正是程式交易架構中 REST API（請求與回應模式） 與 WebSocket（主動即時串流模式） 之間最根本的差異。
許多剛開始接觸自動化交易的投資人，常常撰寫無窮迴圈每秒數次頻繁呼叫 REST 端點抓取即時報價，結果不僅容易觸發券商系統的請求頻率限制（Rate Limit）遭到暫時封鎖，更容易在行情劇烈跳水時產生數百毫秒的致命延遲。深入理解這兩種資料通道的定位，是打造穩健交易系統的基本功。
REST API 採用請求-回應機制：每個邏輯互動為單次請求與回應，而底層 HTTP 連線通常可透過 Keep-Alive 保持複用。這種方式非常適合批次下載歷史 K 棒做回測、查詢帳戶資產快照與低頻交易指令。WebSocket 則是藉由握手建立長期的雙向 TCP 連線通道，伺服器在市場發生事件時主動推播至客戶端。WebSocket 是串流市場行情的常見選擇，但業界同樣存在其他即時傳輸協定。
| 通訊特徵 | REST API (單次請求與回應) | WebSocket (長連線雙向推播) |
|---|---|---|
| 連線運作週期 | 單次互動請求-回應（底層 HTTP 連線可複用 Keep-Alive） | 持久雙向長連線：初始握手後長期保持開啟 |
| 資料傳輸模式 | 客戶端單向拉取（Pull 架構，按需發起） | 伺服器事件驅動主動推播（Push 架構，有變動即推播） |
| 網路延遲水準 | 取樣延遲受輪詢間隔與往返傳輸影響 | 事件驅動推播（撮合成交或變動後即刻發出） |
| 呼叫頻率限制 | 高頻重複輪詢極易引發 HTTP 429 錯誤並遭伺服器頻控限制 | 複用單一長連線通道，免除高頻重複請求帶來的頻控壓力 |
| 核心適用場景 | 下載數年份歷史回測資料、定期產製財務報表、每日低頻換股 | 盤中逐筆報價監控、委託簿五檔深度動態刷新、即時觸價成交回報 |
新手常見盲點：盲目高頻輪詢 REST 的系統災難
許多剛寫腳本的交易者常寫出 `while True: fetch_price(); sleep(0.2)` 的程式碼，試圖透過極短間隔的輪詢獲取即時報價。
這種設計在實盤中往往帶來兩大問題：頻控超限與取樣延遲盲區。
即便在底層複用 HTTP 連線的情況下，過於密集的高頻輪詢依然會帶來龐大的無效請求開銷，極快觸發 API 429（Too Many Requests）頻控門檻甚至遭暫時封鎖。更嚴重的問題在於：若市場於兩次輪詢的空檔內發生劇烈波動，程式在下次請求返回前處於完全的盲區，無法做到即時反應。
與 REST 失敗時會立即回傳明確錯誤碼不同，WebSocket 在面臨底層網路靜默斷線時，作業系統可能不會立即收到關閉訊號（TCP 半開狀態）。程式表面上看似正常在線，實際上早已收不到任何最新報價。專業交易程式必須設計心跳偵測（Ping-Pong Heartbeat），並遵循資料服務商特定心跳與重連規則，及時發現假死連線並恢復通道。
專業法人架構：混合型資料通道設計
成熟的量化交易系統通常不偏廢其一，而是將兩者巧妙整合成互補的架構：
- 11. 系統啟動階段以 REST 初始化狀態： 程式開啟時，發送正規的 REST API 請求，精確取得當前可用資金、現有持倉部位、有效委託單與歷史前 500 根 K 棒快照。
- 22. 盤中執行階段以 WebSocket 接收事件： 初始化完成後立即開啟 WebSocket 連線，持續訂閱最新逐筆成交行情、委託簿買賣報價更新以及即時委託成交回報（Order Execution Report）。
- 33. 週期性以 REST 進行帳務對帳（Reconciliation）： 每隔 10 至 15 分鐘發起一次低頻 REST 查詢，核對本地記憶體狀態與券商後台真實帳本，防範連線中斷或偶發掉包導致的資料累積偏差。
常見問題
可以在 WebSocket 連線上直接送出下單委託嗎？
部分新興衍生品交易平台（如加密貨幣與現代期貨介面）支援透過 WebSocket 直接發送買賣下單與刪單指令；然而多數傳統證券券商仍基於審計與資安考量，嚴格限制下單必須透過經簽章驗證的 REST 或專用 FIX 通訊協定進行。
為什麼免費公開的 API 行情往往比即時報價慢了 15 分鐘？
這是全球主要證券交易所統一的商業版權授權法規。免費且不需認證的公共報價通常被強制延遲 15 分鐘；若要取得無延遲的即時撮合資訊，必須向交易所申請商業授權或透過具備造市資格的持牌券商取得即時 API 金鑰。
遇到網路不穩導致頻繁斷線重連時，該如何設計重試邏輯？
應採用「指數退避演算法（Exponential Backoff with Jitter）」，在斷線後依序等待 1 秒、2 秒、4 秒、8 秒逐步拉長重試間隔並加入隨機時間微調，避免短時間內對券商伺服器造成連線轟炸而遭徹底封鎖。
