搞懂 HTTP 协议,交易所 API 文档瞬间变简单-夜雨聆风

搞懂 HTTP 协议,交易所 API 文档瞬间变简单

今天我们来聊聊 Crypto 量化交易中最基础的知识——REST API 与 HTTP 协议。无论你使用的是币安、OKX 还是其他交易所，这些基础知识都是必须掌握的核心内容。

一、Crypto 的 REST API 量化接口与 HTTP 协议

REST API 是一种基于 HTTP 协议的接口设计风格，也是目前 Crypto 交易所提供量化接口的主流方式。简单来说，REST API 就是交易所为量化开发者提供的“遥控器”，让我们能够通过程序向交易所发送指令——查询余额、下单交易、获取行情等。

“

💡 在 Crypto 量化中，REST API 主要负责账户操作和交易执行，而实时行情通常由 WebSocket API 负责，两者配合使用。

二、HTTP 的请求结构与响应结构

1. HTTP 请求结构（我们发给交易所）

一次 HTTP 请求包含三个部分：请求行、请求头、请求体。

POST /api/v3/order HTTP/1.1          ← 请求行Host: api.binance.com                ← 请求头X-MBX-APIKEY: your-api-keyContent-Type: application/json                                      ← 空行{                                     ← 请求体  "symbol": "BTCUSDT",  "side": "BUY",  "quantity": "0.001"}

请求行：包含 HTTP 方法（GET/POST）、请求路径、HTTP 版本
请求头：键值对形式的元信息，如 API 密钥、数据格式（Content-Type）
请求体：实际发送的数据。GET 请求通常没有请求体，POST 请求多使用 JSON 格式

2. HTTP 响应结构（交易所回给我们）

交易所处理完请求后，返回的响应同样包含三部分：状态行、响应头、响应体。

HTTP/1.1 200 OK                       ← 状态行Content-Type: application/json        ← 响应头                                      ← 空行{                                     ← 响应体  "orderId": 123456789,  "status": "NEW"}

状态行中的状态码非常关键，量化开发者必须熟练掌握：

状态码	含义	量化场景
200	成功	查询/下单成功
400	参数错误	签名错误、缺少必要参数
401	未认证	API 密钥无效
429	请求过多	触发限频，需要等待
500	服务器错误	交易所内部异常

响应体返回的是实际数据，通常为 JSON 格式，包含账户信息、订单详情或错误描述。

三、量化主要接口：GET 和 POST

在 Crypto 量化中，90% 以上的交易所 API 接口仅使用 GET 和 POST 两种方法。

GET 方法：获取数据

GET 用于从服务器获取资源，只读不写，不会改变账户状态。

GET /api/v3/account HTTP/1.1Host: api.binance.comX-MBX-APIKEY: your-api-key

GET 请求的参数全部放在 URL 中，我们来拆解一下 URL 的各个组成部分：

https://www.example.com:443/api/users/123?name=zhang&page=1#section\___/  \____________/ \__/ \____________/ \_________________/ \______/ 协议      域名         端口       路径           查询参数         锚点

组成部分	示例	说明
协议	`https://`	加密传输，Crypto 量化中必须使用
域名	`www.example.com`	交易所 API 服务器地址
端口	`:443`	HTTPS 默认端口，通常可省略
路径	`/api/history/123`	资源位置，`123` 为路径参数（用于定位具体资源）
查询参数	`?name=zhang&page=1`	筛选、分页、排序等条件
锚点	`#section`	页面定位，不会发送到服务器

路径参数用于定位具体资源，如 /history/123 中的 123 指定了要查询哪段历史。查询参数用于附加筛选条件，例如分页（page=1）、排序、关键词搜索等。

GET 典型场景：查历史行情数据、获取服务器相关基础信息。

优点：简单直观、可缓存、幂等且安全。

限制：URL 长度有限（2KB–8KB），敏感信息会暴露在 URL 中。

POST 方法：提交操作

POST 用于向服务器提交数据，会改变账户状态（如下单、撤单）。

POST /api/v3/order HTTP/1.1Host: api.binance.comX-MBX-APIKEY: your-api-keyContent-Type: application/json{  "symbol": "BTCUSDT",  "side": "BUY",  "type": "LIMIT",  "price": "50000",  "quantity": "0.001"}

POST 请求的参数主要放在请求体（Body）中，在量化交易中统一使用 JSON 格式。

为什么 POST 选择 JSON？因为 JSON 支持复杂的嵌套结构（如登陆密钥），支持数组（便于批量下单），没有长度限制，可读性强，且各主流编程语言都有成熟的解析库。

POST 典型场景：下单、批量下单、撤单、提现、设置杠杆。

优点：无长度限制、支持复杂数据结构、安全性更高（参数不暴露在 URL 中）。注意：POST 不具备幂等性，多次调用会生成多个订单，需要使用 clientOrderId 防止重复提交。

GET vs POST 速查

对比项	GET	POST
用途	查询数据	提交操作
参数位置	URL 中（路径参数 + 查询参数）	请求体中（JSON 格式）
是否改变状态	否（只读）	是（写入）
幂等性	✅ 是	❌ 否
典型场景	查行情	下单、撤单

一句话原则：查数据用 GET，写操作用 POST。

四、其他 REST API 的 HTTP 方法

除 GET 和 POST 外，REST API 中还定义了其他几种 HTTP 方法：

DELETE：用于删除指定资源
PUT：用于全量更新资源，即用完整的新资源替换原有资源
PATCH：用于部分更新资源，仅修改资源中的指定字段
HEAD：仅获取响应头，不获取响应体，常用于检测资源是否存在或获取元信息
OPTIONS：用于查询服务器支持的 HTTP 方法，通常用于接口探测或跨域请求预检

已为您精简总结部分：

五、总结

REST API：基于 HTTP 的接口风格，是量化程序与交易所的通信桥梁，配合 WebSocket 使用
HTTP 结构：请求（请求行+请求头+请求体）与响应（状态行+响应头+响应体），状态码是排错关键（200成功、400参数错误、401认证失败、429限频）
GET vs POST：GET查数据（参数放URL），POST写操作（参数放JSON请求体），原则：查用GET，写用POST
其他方法：DELETE、PUT、PATCH、HEAD、OPTIONS，特定场景补充使用

掌握这些基础知识，再看交易所 API 文档时，你会发现原本晦涩的接口说明变得清晰明了——你知道每个参数该放哪里，每个状态码意味着什么，每种 HTTP 方法该如何选择。这是写出稳健、高效的量化交易程序的第一步，也是最重要的一步。

如果觉得有帮助，欢迎点赞、在看、转发支持！