交易所API基础：REST与WebSocket协议对比，API密钥管理与安全规范，常见交易所API文档解读方法
做量化交易，第一关就是跟交易所打交道。说白了，你得学会怎么跟交易所的服务器「说话」。我见过不少新手，策略写得挺漂亮，结果连API都连不上，那真是白搭。
这一章，咱们就聊聊交易所API的那些基础事儿。我会把REST和WebSocket的区别讲清楚，再聊聊密钥管理那些坑，最后教你如何快速读懂一份交易所API文档。
REST vs WebSocket：两种通信方式的抉择
交易所API主要就两种：REST和WebSocket。很多人纠结选哪个，其实没那么复杂。
REST API：一问一答的模式
REST API就像你给交易所发微信：「当前BTC价格多少？」交易所回复：「50000 USDT。」然后对话结束。每次请求都是独立的，你问一句，它答一句。
我个人习惯把REST API用在这些场景：
- 查询账户余额——不需要实时更新，查一次管一会儿
- 下单、撤单——交易操作，一次性的
- 获取历史K线数据——拉取过去的数据，不需要实时推送
REST的优点很明显：简单、稳定、容易调试。但缺点也致命——有延迟。你想想看，每次都要发请求、等响应，如果行情波动快，等你拿到价格再下单，黄花菜都凉了。
重要提醒：REST API有频率限制。我在项目中遇到过，一个新手同事写了个死循环去查价格，结果被交易所封了IP整整24小时。嗯，从那以后他再也不敢这么干了。
WebSocket：建立一条专线
WebSocket就不同了。它像你跟交易所之间拉了一条专线，交易所那边一有变化，直接推送到你这儿：「BTC价格变了，现在是50001 USDT！」
WebSocket最适合：
- 实时行情订阅——深度、成交、Ticker
- 订单状态推送——你的单子成交了，交易所主动告诉你
- 账户变动通知——余额变化、持仓变化
为什么需要WebSocket？你想想看，如果用REST去轮询深度数据，每秒请求一次，不仅慢，还容易被封。而WebSocket建立一次连接，数据就源源不断地推过来，延迟通常在毫秒级别。
我的建议：实际项目中，REST和WebSocket是配合使用的。WebSocket负责实时行情推送，REST负责下单和查询。别想着只用一种搞定所有事情。
协议对比一览
| 对比维度 | REST | WebSocket |
|---|---|---|
| 通信模式 | 请求-响应 | 全双工推送 |
| 延迟 | 较高（50-200ms） | 低（1-10ms） |
| 连接方式 | 短连接，每次请求新建 | 长连接，保持不断 |
| 适用场景 | 查询、下单、历史数据 | 实时行情、订单推送 |
| 频率限制 | 严格，容易触发 | 相对宽松 |
| 实现复杂度 | 低 | 中高（需处理重连） |
API密钥管理与安全规范
说到密钥管理，这可是重中之重。我见过有人把API密钥直接写在代码里，然后上传到GitHub……结果可想而知，账户被洗劫一空。
密钥的组成
交易所API密钥通常有两部分：
- API Key：相当于你的用户名，标识你是谁
- Secret Key：相当于你的密码，用来签名请求
有些交易所还会要求设置Passphrase（密码短语），作为额外的安全层。
安全规范，我踩过的坑
我曾经犯过一个错误：为了方便测试，给API密钥开了「交易」和「提现」的全部权限。结果测试脚本出了bug，疯狂下单，差点把账户亏空。嗯，从那以后我学乖了。
警告：永远遵循最小权限原则。只给API密钥分配它需要的权限。比如只做行情分析的脚本，就不要给它交易权限。更不要开提现权限——除非你真的需要程序自动提现。
我的密钥管理习惯：
- 使用环境变量——把密钥写在.env文件里，用python-dotenv加载，绝不硬编码
- IP白名单——在交易所后台设置，只允许你的服务器IP访问
- 定期轮换——每隔一段时间换一次密钥，旧密钥及时删除
- 多账户隔离——测试账户和实盘账户用不同的密钥
来看一个简单的Python示例：
import os
from dotenv import load_dotenv
load_dotenv()
API_KEY = os.getenv('EXCHANGE_API_KEY')
SECRET_KEY = os.getenv('EXCHANGE_SECRET_KEY')
PASSPHRASE = os.getenv('EXCHANGE_PASSPHRASE')
# 千万别这样写：
# API_KEY = 'your-api-key-here'
# SECRET_KEY = 'your-secret-key-here'
签名机制
每次请求REST API时，都需要用Secret Key对请求参数进行签名。交易所收到请求后，会用你注册的Secret Key验证签名是否匹配。这样即使API Key泄露了，没有Secret Key也发不了请求。
签名流程大致是：
- 拼接请求参数（时间戳、方法、路径、参数等）
- 用HMAC-SHA256算法对字符串进行加密
- 将签名结果放在请求头中发送
不同交易所的签名细节略有不同，但核心逻辑是一样的。我建议你封装一个统一的签名函数，这样对接多个交易所时能省不少事。
常见交易所API文档解读方法
拿到一份API文档，很多人直接懵了。几百页的文档，从哪看起？
我的方法是「三步走」：
第一步：先看概览
找到文档的「Overview」或「Introduction」部分。这里会告诉你：
- API的基础URL是什么
- 支持哪些协议（REST、WebSocket）
- 频率限制是多少
- 认证方式是什么
这些信息决定了你后续的开发方向。比如频率限制是每秒10次还是100次，直接影响到你的请求策略。
第二步：找到核心接口
别从头到尾读一遍，没那个必要。直接找这几个关键接口：
- 获取行情——/api/v3/ticker/price 之类的
- 下单——/api/v3/order
- 查询订单——/api/v3/order/{orderId}
- 查询账户——/api/v3/account
每个接口看三样东西：请求方法（GET/POST）、请求参数、响应格式。
第三步：看错误码和限制
这部分容易被忽略，但恰恰是最重要的。我遇到过最坑的一次：某个交易所的API文档里写的是「-1001: Invalid parameter」，但实际上返回的是「-1002: Signature error」。你想想看，如果只看文档不看实际响应，debug能把你搞疯。
小技巧：用Postman或curl先手动调通一个接口，确认文档描述和实际行为一致。然后再开始写代码。这一步能省下你至少半天的时间。
知识体系总览
下面这张图，把本章的核心内容串起来了：
说白了，这一章讲的就是怎么跟交易所「安全、高效地对话」。协议选对了，密钥管好了，文档读懂了，后面的开发就顺风顺水。我见过太多人在这三步上栽跟头，结果后面debug debug到怀疑人生。
嗯，记住一句话：先慢后快。花时间把基础打牢，比什么都强。