金融市场数据 API：如何通过 REST API 获取实时股票数据

做股票看板的时候，真正麻烦的往往不是第一次把股票价格取出来，而是项目做着做着，发现需要的数据越来越多。

最开始可能只想显示一个实时价格，后来又要加历史 K 线、同时查询多个股票，再往后还可能需要买卖盘数据。到了这个阶段，直接从财经网站抓数据就开始显得有些勉强了。页面结构会变，数据格式也不一定稳定，维护成本很容易随着功能一起往上走。

这也是为什么很多开发者会开始考虑 金融市场数据 API。相比从网页里提取数据，API 可以直接返回结构化的市场数据，应用只需要处理自己真正需要的部分。

而且，并不是一提到“实时股票数据”，就必须马上上 WebSocket。对于不少看板、投资组合工具、市场监控页面来说，REST API 已经可以解决相当一部分问题。

REST API 能解决哪些股票数据需求？

理解 REST 在金融数据场景里的作用，其实不需要想得太复杂。

可以把它理解成几个很具体的问题：现在这只股票的最新成交价是多少？最近 100 根 K 线是什么？当前的买一和卖一分别是多少？

这些本质上都是“我现在问你一个问题，你把结果告诉我”的场景，所以 REST 很适合。

一个实用的股票市场数据 API，通常不会只有一个价格接口。实际项目里更常见的是把实时行情、历史 K 线以及一些辅助信息组合起来使用。

并不是每个项目都需要全部数据。真正重要的是，当需求增加时，数据接口能够跟着一起扩展，而不用重新搭一套完全不同的系统。

为什么 REST 依然适合实时股票数据？

很多人看到“实时股票数据”，第一反应就是 WebSocket。

其实不一定。

如果你的应用只是每几秒刷新一次关注列表，或者用户打开股票详情页时需要拿一次最新价格，那么 REST 已经足够直接。请求一次，拿到 JSON，更新页面，就这么简单，也不需要额外维护一条长期连接。

AllTick 的 REST API 就比较适合这种请求式的数据获取方式。最新行情接口可以一次请求多个股票代码，返回最新成交信息，包括股票代码、时间戳、价格、成交量、成交额等字段。

例如：

{
  "ret": 200,
  "msg": "ok",
  "data": {
    "tick_list": [
      {
        "code": "857.HK",
        "seq": "30841439",
        "tick_time": "1677831545217",
        "price": "136.302",
        "volume": "0",
        "turnover": "0",
        "trade_direction": 0
      }
    ]
  }
}

对开发者来说，最方便的地方其实不是接口地址本身，而是返回的数据已经是结构化的。拿到以后，你可以直接交给前端展示，也可以放进缓存、数据库，或者继续用于自己的业务逻辑。

需要注意的一点是，这类“最新行情”接口返回的是当前最新成交数据，并不是历史逐笔成交查询。如果需求是回看过去的 Tick 数据，就要选择不同的数据方案。

历史 K 线同样重要

只看当前价格，往往很难让一个股票页面真正有用。

用户通常还想知道，价格之前是怎么走的。开发者也是一样：做图表需要历史 K 线，做分析需要历史数据，哪怕只是一个简单的股票页面，也很少有人会满足于只看到一个实时数字。

这正是 股票市场数据 REST API 比较方便的地方。历史数据本身就是典型的查询场景：指定股票、K 线周期以及需要的数据量，然后拿回结果。

AllTick 的 REST K 线接口支持 1 分钟、5 分钟、15 分钟、30 分钟、小时、日、周、月等周期。对于股票数据，最短周期为 1 分钟，同时股票不支持 2 小时和 4 小时 K 线。

返回的数据结构也比较熟悉：

{
  "timestamp": "1677829200",
  "open_price": "136.421",
  "close_price": "136.412",
  "high_price": "136.422",
  "low_price": "136.407",
  "volume": "0",
  "turnover": "0"
}

对于大多数图表场景，这些字段已经足够使用。应用可以先加载历史 K 线，再把最新行情接进来，这样页面一打开就有完整的价格走势，而不是等实时数据慢慢堆出来。

如果要同时看很多股票怎么办？

一个股票很好处理，十个也不算麻烦。但如果一个看板里已经放了几十只股票，甚至更多，开发方式就会发生变化。

最直接的办法是每个股票单独请求一次，但请求数量很快就会上去。如果不同模块又重复请求同一个股票的数据，就更浪费了。

这种情况下，批量查询就有价值了。

AllTick 提供批量 K 线接口，可以一次处理多个产品和多个 K 线类型，更适合用来加载多股票看板的初始数据。不过它的批量接口主要针对最新数据，并不是用来替代大范围历史 K 线查询的。

换句话说，批量请求适合“我现在想同时拿到这批股票的最新状态”，而单产品历史查询适合“我想把这只股票过去的数据拉回来”。

什么时候需要盘口数据？

如果只是做一个普通的股票价格列表，最新成交价可能就够了。

但如果你在做更细一点的行情页面，只显示最后成交价就会少一些信息。比如股票现在成交在 136.30，那么当前买方愿意出多少、卖方在什么价格挂单，其实并没有体现出来。

这时候就会用到盘口数据。

盘口接口可以返回 Bid 和 Ask 的价格及数量，应用可以据此展示当前买卖价差，也可以做简单的深度可视化。

{
  "code": "857.HK",
  "bids": [
    {
      "price": "136.424",
      "volume": "100000.00"
    }
  ],
  "asks": [
    {
      "price": "136.427",
      "volume": "400000.00"
    }
  ]
}

不过，我不会建议为了“功能看起来更完整”就把所有数据都接进来。没有实际需求的字段，只会增加请求量和处理逻辑。如果产品只是一个投资组合看板，盘口可能根本没有必要；如果是市场监控工具，那它的价值就完全不同了。

股票数据不只是价格

还有一类信息不怎么“实时”，但在实际产品里一样重要，那就是股票基础信息。

应用拿到 700.HK 之后，还得知道它对应的股票名称、交易所、交易币种等信息。如果页面需要展示更多内容，还可能用到总股本、流通股本、每手股数、EPS、股息率等字段。

AllTick 的股票信息接口可以批量获取美股、港股和 A 股的部分基础信息。

这些信息没必要像实时价格一样高频请求。更合理的做法是单独缓存，只有在需要更新时再刷新。

同样的逻辑也适用于交易状态。对于停牌股票，如果应用只知道最后一个价格，却不知道它其实已经停止交易，那么用户很容易误以为数据出了问题。SSE、NYSE 和 Nasdaq 的交易状态信息可以为这类场景补上必要的上下文。

一个简单的 REST 接入方式

实际接入并没有想象中复杂。

AllTick 使用 X-API-Key 作为认证请求头。以最新行情为例，只需要把需要查询的股票代码放进请求体，就可以得到结构化 JSON 数据。

Python 示例：

import requests

API_KEY = "YOUR_API_KEY"

url = "https://quote.alltick.co/quote-stock-b-api/v1/quote"

payload = {
    "trace": "stock-demo-001",
    "data": {
        "symbol_list": [
            {"code": "857.HK"},
            {"code": "UNH.US"}
        ]
    }
}

response = requests.post(
    url,
    headers={
        "X-API-Key": API_KEY,
        "Content-Type": "application/json"
    },
    json=payload,
    timeout=10
)

response.raise_for_status()

result = response.json()

for item in result.get("data", {}).get("tick_list", []):
    print(item["code"], item["price"], item["tick_time"])

第一版其实做到这里就可以了。先把数据拿到，再决定它最终进入看板、数据库还是业务逻辑，没有必要一开始就把整个数据架构做得很重。

REST 和 WebSocket 怎么选？

真正需要考虑 WebSocket，通常是因为“更新频率”和“股票数量”开始上来了。

如果系统只是定时刷新少量股票，REST 完全可以继续用。但如果需要持续监控大量股票，而且希望市场变化发生后就尽快得到更新，那么不断轮询每个股票就会越来越别扭。

这时候 WebSocket 更适合。

我更倾向于把两者看成互补关系，而不是二选一：

历史数据 / 页面初始化
          ↓
        REST
          ↓
      应用数据层
          ↑
      WebSocket
          ↑
      实时更新

REST 负责历史数据和按需查询，WebSocket 负责持续推送。这样既不会让一个小项目一开始就背上复杂的连接管理，也不会在需求变大以后被轮询方式卡住。

实际开发时，有几个细节值得提前处理

API 接口本身通常不是最容易出问题的地方，真正麻烦的往往在外围。

API Key 不要直接放到前端代码里。多个页面组件也不要各自维护一套轮询逻辑，否则同一个股票可能被重复请求很多次。把请求集中到一个数据层，再配合短时间缓存，通常会简单得多。

股票代码也要特别注意。代码需要和数据源提供的产品标识严格匹配，包括大小写，不要觉得“差不多”就可以。

另外，不同数据的更新频率并不一样。实时价格需要频繁更新，历史 K 线没有必要每隔几秒重新下载，股票基础信息更不应该跟着实时行情一起刷新。把这些数据分开处理，整个系统会轻很多。

一个更实际的开发路径

如果让我从零开始做一个股票数据项目，我不会一开始就把所有东西接满。

先获取最新股票价格，再加入历史 K 线，把页面真正跑起来。需要同时处理更多股票时，再增加批量请求；产品确实需要买卖盘时，再引入盘口；当实时更新的规模真正上来以后，再把这一部分切到 WebSocket。

AllTick 在这个过程中比较自然，因为它的 REST 接口已经覆盖了股票应用最常见的几类需求，后面如果需要更连续的实时更新，也可以继续往 WebSocket 扩展。

这种方式更实际。

不是先把所有 API 能力研究一遍，再想产品怎么用，而是先解决用户真正的问题，再决定下一步需要什么数据。

如何选择适合自己的金融市场数据 API？

我在选择 金融市场数据 API 时，更关心的其实不是“有多少接口”，而是它能不能顺着我的项目一起成长。

能不能稳定拿到最新价格？能不能获取历史 K 线？多个股票能不能合理处理？如果以后需要持续的实时行情，能不能从 REST 平滑过渡到 WebSocket？

这些问题比“接口数量是不是足够多”更实际。

对于很多股票应用来说，REST 是很好的起点。它简单、容易调试，也适合最新价格和历史数据这类请求式需求。当应用真的需要持续接收大量市场更新时，再把实时部分交给 WebSocket。

这样做出来的数据层不会太重，但也不会因为项目稍微扩大一点就推倒重来。

最终，真正有价值的并不是把所有市场数据都收集进来，而是让正确的数据在正确的时间进入产品，而且开发者能够长期维护它。