ch13-11 Server REST API

返回本章

先看数据问题

这一节从读模型而不是数据库表开始。围绕“Server REST API”，先问交易终端、机器人或风控系统要查什么，再看 handler 和 schema 如何支撑。

源码入口

• crates/server/src/server.rs：REST API、数据库查询、健康检查或指标实现。
• crates/server/src/reader.rs：REST API、数据库查询、健康检查或指标实现。
• crates/server/src/writer.rs：REST API、数据库查询、健康检查或指标实现。
• crates/server/README.md：REST API、数据库查询、健康检查或指标实现。

落到读模型里

crates/server/src/server.rs 暴露 DeepBook 和 Margin 数据 API。核心路径包括：

• /get_pools：池子列表。
• /ticker：行情摘要。
• /trades/:pool_name：成交记录。
• /order_updates/:pool_name：订单更新。
• /orders/:pool_name/:balance_manager_id：用户订单。
• /orderbook/:pool_name：二级订单簿。
• /ohclv/:pool_name：K 线。
• /loan_borrowed、/loan_repaid、/liquidation：Margin 事件。
• /status：Indexer 健康状态。

Server 同时会做链上只读调用，例如订单簿 level2、费用参数、DEEP supply。应用要区分数据库读模型和链上实时读模型的延迟差异。

REST 层把数据库读模型、链上只读 RPC 和管理端点拆开。行情、历史成交和 Margin metrics 走只读 reader；需要触发写操作或管理行为时应经过明确鉴权、限流和错误码映射，避免前端把内部错误直接展示成交易失败原因。

数据系统判断

• 先确认本节涉及的事件名、handler、目标表和 API 端点，避免把链上对象状态与读模型混用。
• 查询设计必须带池子、账户、checkpoint 或时间窗口，并说明分页和索引依据。
• 对实时应用要同时检查 /status、checkpoint lag 和数据时间戳，再决定是否交易、降级或告警。
• 涉及 Flash Loan 或 Margin 时，明确 flashloans 与 loan_borrowed、loan_repaid 的语义差异。

动手检查

• 本节对应的 handler、表名和 Server 查询入口分别是什么？
• 这个数据在链上、Indexer、PostgreSQL、Server 缓存和前端之间可能出现哪些延迟或不一致？
• 如果用于机器人或风控，应该设置什么 checkpoint lag、分页窗口和降级策略？