Hyperliquid REST vs WebSocket：什么时候用哪个

• hyperliquid rest websocket

• hyperliquid api types

• Hyperliquid REST API

• Hyperliquid WebSocket

locale: zh-CN

很多开发者在接入 Hyperliquid API 时面临同一个问题：我的策略应该用 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 下载 支持桌面和移动端，GitHub 上的开源代码可以帮助开发者理解签名集成的具体实现。

混合架构：最佳实践

实际生产环境中，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 钱包 作为签名后端，可以在不牺牲安全性的前提下构建稳健的链上交易系统。前往 OneKey 官网 了解 OneKey Perps 如何让普通用户也能享受 Hyperliquid 深度流动性，或访问 下载页 立即上手。

---免责声明---

本文内容仅供技术学习参考，不构成投资建议。自动化交易策略存在代码缺陷、网络故障等技术风险，可能导致意外亏损。永续合约高杠杆交易风险极高，请在充分评估自身技术能力和风险承受能力后谨慎参与。