一、交易所API协议概述
什么是交易所API
说白了，交易所API就是程序跟交易所服务器对话的「翻译官」。你写个Python脚本，想下单、查余额、看行情，总不能手动点网页吧？API就是干这个的。
我刚开始做量化那会儿，觉得API就是个接口文档。后来踩的坑多了才发现——API协议的设计，直接决定了你的交易系统稳不稳、快不快。
举个例子。你写了个策略，信号来了要抢着下单。如果API延迟高个几百毫秒，行情早变了。这就是为什么我们要深入理解协议本身。
核心定义：交易所API是交易所提供的、允许程序化访问交易功能的接口集合。它定义了数据格式、通信规则、认证方式等标准。
常见的交易所API协议类型
目前主流的就三种：REST、WebSocket、FIX。我一个个说。
1. REST API
REST，全称Representational State Transfer。听着玄乎，其实就是HTTP请求那一套。你发个GET拿数据，发个POST下订单。
特点：
- 请求-响应模式：你问一句，它答一句
- 无状态：每次请求都是独立的
- 基于HTTP：简单，谁都会用
适用场景：
- 查询账户余额、历史订单
- 低频交易（比如几分钟一次）
- 非实时行情获取
我的经验：REST最适合做「查数据」的事。我在做回测系统时，就用REST拉历史K线。但千万别用它做高频交易——轮询太慢了。
2. WebSocket API
WebSocket是长连接。建立一次连接，服务器可以主动推数据给你。实时行情、成交回报，全靠它。
特点：
- 全双工通信：两边都能随时发消息
- 低延迟：建立连接后，没有HTTP的握手开销
- 推送模式：不用你轮询，有数据就推过来
适用场景：
- 实时行情订阅（tick级数据）
- 订单状态实时更新
- 高频交易策略
注意：WebSocket虽然快，但连接不稳定。我曾经在实盘中遇到WebSocket断连，行情停了5秒，策略还在傻等。后来我加了心跳检测和自动重连机制，才算稳了。
3. FIX协议
FIX，Financial Information eXchange。金融圈的老牌协议，机构级标准。它不依赖HTTP，有自己的消息格式和会话层。
特点：
- 二进制或文本格式：效率高
- 会话管理完善：登录、心跳、序列号、重传
- 标准化程度高：全球通用
适用场景：
- 机构级交易系统
- 做市商、高频交易
- 跨交易所统一接入
一句话总结：REST适合查数据，WebSocket适合收实时行情，FIX适合机构级高频交易。
协议选择与适用场景
选哪个协议？我个人的经验是：看你的交易频率和系统架构。
| 场景 | 推荐协议 | 原因 |
|---|---|---|
| 查询历史数据 | REST | 简单，一次请求搞定 |
| 实时行情展示 | WebSocket | 推送模式，延迟低 |
| 手动下单 | REST | 偶尔操作，没必要长连接 |
| 程序化高频交易 | WebSocket + FIX | WebSocket收行情，FIX下单 |
| 机构级做市 | FIX | 标准化、可靠、低延迟 |
你想想看，如果只是每天跑一次策略，用REST完全够。但如果你做的是tick级高频，不用WebSocket或FIX，基本没戏。
避坑指南：我曾经在一个项目里，为了省事只用REST做实时行情。结果轮询间隔100ms，CPU跑满不说，行情还经常滞后。后来换成WebSocket，CPU降到5%，延迟从100ms降到10ms。嗯，选对协议太重要了。
知识体系总览
下面这张图，是我梳理的交易所API协议的核心知识结构。你可以把它当作本章的「地图」。
这张图把三种协议的核心特征都列出来了。你看，REST是「请求-响应」，WebSocket是「推送」，FIX是「标准化会话」。理解了这个，后面学具体实现就轻松多了。
本章核心：没有最好的协议，只有最合适的。选协议前，先想清楚你的交易场景。
公众号:蓝海资料掘金营，微信deep3321