Hyperliquid REST vs WebSocket：幾時應該用邊個？

• hyperliquid rest websocket

• hyperliquid api types

• Hyperliquid REST API

• Hyperliquid WebSocket

好多開發者接入 Hyperliquid API 時，都會遇到同一個問題：我的策略應該用 REST，定係 WebSocket？兩種接口背後嘅技術機制好唔同，適合嘅場景亦完全唔一樣。揀錯輕則浪費頻寬同資源，重則影響策略時效，令落盤滑點遠超預期。

本文會系統拆解 REST 同 WebSocket 嘅運作原理、適用場景、延遲特性同常見陷阱，幫你判斷幾時應該用邊一種。

REST API：請求—回應模型

REST（Representational State Transfer）係最經典嘅 HTTP 接口模式：客戶端發出請求，伺服器返回回應，一問一答，之後連線結束。Hyperliquid 官方文件將 REST 接口分為兩類端點。

Info 端點（/info）處理所有只讀查詢，例如現時市場元數據、歷史成交、帳戶持倉快照。呢類請求唔需要簽名，任何客戶端都可以調用。

Exchange 端點（/exchange）處理所有寫入操作，包括落盤、取消訂單、修改槓桿同調整保證金。呢類請求必須附帶 EIP-712 結構化簽名，伺服器會驗證簽名來源同帳戶地址一致，先會執行。

REST 嘅典型應用場景

一次性數據查詢係 REST 最適合嘅場景。例如：策略啟動時拉取當前持倉狀態、定期檢查帳戶餘額、按需要取得某個合約嘅資金費率歷史。呢啲操作無即時性要求，發一次請求、攞一次答案就夠，唔需要維持長連線。

落盤同取消訂單亦係透過 REST 完成。即使策略需要即時市場數據，真正嘅交易指令仍然要經 Exchange 端點以 REST 方式提交，呢點係硬性要求，無得繞過。

大量歷史數據拉取同樣適合 REST。例如做回測時，需要下載大量歷史成交或者 K 線數據，用分頁方式循環調用 Info 端點，效率通常可以接受。

REST 嘅局限

REST 最大嘅限制係「拉取」模式——你唔會知道市場幾時會變，只能夠定期輪詢。如果每 100ms 輪詢一次訂單簿，好容易撞到速率限制；如果降到每秒一次，喺快速行情入面，策略可能已經慢咗半拍。

對於需要即時回應市場變化嘅策略，高頻輪詢既低效，亦唔可靠。

WebSocket：持久連線與即時推送

WebSocket 係一種全雙工協議，建立一次連線之後，伺服器可以主動向客戶端推送數據，唔需要客戶端反覆發請求。Hyperliquid 嘅 WebSocket 端點係：

wss://api.hyperliquid.xyz/ws

連線建立後，客戶端透過發送訂閱訊息，聲明自己想接收邊類數據；之後伺服器會持續推送相關更新事件，直至連線中斷，或者客戶端主動取消訂閱。

WebSocket 嘅典型應用場景

即時訂單簿監控係 WebSocket 最典型嘅用途。訂閱 l2Book 頻道後，每次訂單簿有變化，都會收到增量或全量更新，策略可以喺毫秒級別感知市場深度變化。

即時成交流（trades 頻道）適合監控市場衝擊同成交節奏，係判斷當前市場情緒嘅實用訊號。

帳戶事件訂閱（userEvents 頻道）可以即時知道成交回報、清算通知等帳戶級別重要事件，唔需要額外輪詢帳戶狀態。

資金費率即時追蹤對套利策略尤其重要。透過 WebSocket，可以喺資金費率有變化時即時收到通知，而唔係等下一次輪詢週期。

WebSocket 嘅注意事項

連線穩定性係 WebSocket 嘅核心挑戰。網絡波動、伺服器重啟、長時間閒置，都可能令連線斷開。喺生產環境入面，必須實作心跳機制（定期 ping/pong）同自動重連邏輯；重連之後，亦要重新訂閱所有頻道，並處理斷線期間可能遺失嘅數據。

訊息處理壓力亦唔可以忽視。當你訂閱高頻數據源，例如主流合約嘅 L2 訂單簿，訊息推送速度可能非常高。客戶端嘅解析同處理邏輯必須夠快，否則消費隊列積壓，數據會愈來愈滯後，最後反而失去「即時」意義。

詳細對比表

代碼示例對比

REST 查詢訂單簿快照（Python）：

import requests

response = requests.post(
    "https://api.hyperliquid.xyz/info",
    json={"type": "l2Book", "coin": "ETH"}
)

book = response.json()

# 取得當前一刻嘅訂單簿快照，之後唔會自動更新

WebSocket 訂閱訂單簿即時更新（Python）：

import asyncio
import websockets
import json

async def stream_orderbook():
    uri = "wss://api.hyperliquid.xyz/ws"

    async with websockets.connect(uri) as ws:
        await ws.send(json.dumps({
            "method": "subscribe",
            "subscription": {"type": "l2Book", "coin": "ETH"}
        }))

        # 持續接收推送；每次訂單簿變化都會收到新訊息
        async for message in ws:
            data = json.loads(message)

            # 處理即時更新
            print(data)

asyncio.run(stream_orderbook())

兩段代碼嘅分別好明顯：REST 攞一次快照就完；WebSocket 建立連線後會持續接收訊息，直至連線中斷。

落盤請求嘅簽名與 OneKey 整合

無論係透過 REST 落盤，定係透過 WebSocket 監控帳戶事件，只要涉及寫入操作，請求都需要 EIP-712 簽名。簽名密鑰嘅安全性，直接決定咗帳戶嘅安全邊界。

OneKey 錢包提供硬件級別嘅簽名隔離：私鑰儲存在安全芯片入面，任何簽名操作都喺設備內部完成，主機上嘅代碼永遠攞唔到原始私鑰。對量化交易者而言，呢代表即使策略代碼本身有安全漏洞，攻擊者亦無法單靠代碼注入去直接竊取私鑰。

一個較實際嘅工作流程係：策略代碼先構造好待簽名嘅交易請求體，透過 WalletConnect 協議將簽名請求發送到 OneKey 設備；用戶喺設備螢幕上確認後，簽名結果返回策略代碼，再提交到 Hyperliquid Exchange 端點。

呢個流程加入咗人工確認步驟，所以更適合中低頻策略。至於高頻全自動策略，則需要認真評估是否使用專用熱錢包，並將佢同主帳戶隔離管理，避免單點風險擴大。

如果你唔想由零開始處理永續合約交易流程，亦可以考慮直接使用 OneKey Perps。OneKey Perps 將 Hyperliquid 嘅深度流動性同 OneKey 錢包體驗結合，適合想用較清晰流程管理加密貨幣永續合約交易嘅用戶。不論係手動交易，定係配合較低頻嘅策略決策，都可以用 OneKey 作為更安全嘅入口。

OneKey 支援桌面同流動端下載；開源代碼亦有助開發者理解簽名整合嘅具體實作方式。

混合架構：最佳實踐

喺實際生產環境，REST 同 WebSocket 通常唔係互相取代，而係互補。一個典型嘅量化策略架構可能係：

• WebSocket 長連線負責即時訂閱市場數據，例如 L2 訂單簿、成交流、帳戶事件
• REST 負責落盤、取消訂單等交易指令提交
• 策略啟動時，用 REST 一次性拉取帳戶狀態同當前持倉，作為初始化數據
• 定期，例如每小時，用 REST 全量核對一次帳戶狀態，避免 WebSocket 因斷線而出現偏差

呢種混合架構可以同時發揮兩種接口嘅優勢，亦係 Hyperliquid 文件中隱含推薦嘅使用方式。

FAQ

Q1：如果只係做簡單定時落盤策略，需要用 WebSocket 嗎？

唔需要。定時落盤策略嘅核心需求係定時觸發同簽名落盤，兩者都可以透過 REST 完成。策略觸發時先用 REST 查詢當前價格同帳戶狀態，之後構造訂單並提交到 Exchange 端點即可。對呢類策略而言，WebSocket 可能只係額外開銷，反而增加維護複雜度。

Q2：WebSocket 斷線後，我點知自己錯過咗咩數據？

呢個係 WebSocket 開發嘅經典問題。常見做法係：重連後即刻用 REST 拉取當前完整狀態，例如訂單簿快照同帳戶持倉，將佢作為新基準，忽略斷線期間嘅增量更新。至於成交流等歷史數據，可以喺重連後查詢斷線時間段內嘅歷史成交紀錄，盡量補回空白。

Q3：REST 落盤到收到成交回報之間有幾大延遲？

REST 落盤請求嘅回應通常只確認訂單已被接受；實際成交回報需要透過 WebSocket 嘅 userEvents 頻道接收，或者再次輪詢帳戶狀態。整體延遲取決於網絡條件同 Hyperliquid 鏈嘅出塊速度。正常情況下，外界普遍反映延遲相當短，但喺極端行情下仍然可能出現延遲。

Q4：同時開幾多個 WebSocket 連線比較合適？

建議盡量將同一帳戶嘅所有訂閱集中喺少數連線上，避免開太多並發連線而觸發連線數限制。具體上限應以官方文件最新規定為準。多個獨立策略可以透過內部訊息總線共享同一條 WebSocket 連線，減少外部連線數，同時簡化重連管理。

Q5：喺 Jupyter Notebook 入面調試 WebSocket 代碼有咩要注意？

Jupyter 預設 event loop 同 asyncio 可能有兼容性問題，直接運行 asyncio.run() 有機會報錯。建議安裝 nest_asyncio，並喺 notebook 開頭調用 nest_asyncio.apply()；或者將 WebSocket 代碼搬到獨立 Python 腳本入面執行。

結語

REST 同 WebSocket 唔係競爭關係，而係為唔同需求而設計嘅互補工具。簡單講：需要「當刻」數據就用 REST；需要「即時」數據就用 WebSocket；寫入操作永遠透過 REST 完成。

理解呢個分工，就掌握咗 Hyperliquid API 架構嘅核心邏輯。喺呢個基礎上，配合 OneKey 錢包作為簽名後端，可以喺兼顧安全嘅前提下，建立更穩健嘅鏈上交易流程。

如果你想用更直接嘅方式體驗 Hyperliquid 永續合約流動性，可以前往 OneKey 官方渠道下載 OneKey，並使用 OneKey Perps 開始熟悉交易流程。建議先用細額、低槓桿方式測試，確認自己理解風險同操作細節後，再決定是否進一步使用。

---免責聲明---

本文內容只供技術學習參考，不構成投資建議、法律意見或財務建議。自動化交易策略可能涉及代碼缺陷、網絡故障、接口變更等技術風險，並可能導致意外虧損。永續合約及高槓桿交易風險極高，請先充分評估自身技術能力、財務狀況同風險承受能力，再謹慎參與。