用 ord 搭好的铭文资源管理器，平时给人的印象是一页一页的网页：区块页、铭文页、聪的归属页。但同一台 ord server 其实还藏着第二张面孔——把所有页面内容用结构化数据的形式吐出来，这就是它内置的 JSON-API。对想批量核对铭文数据、写自查脚本的人来说，这条路径比复制粘贴网页字段可靠得多。
开关不是参数，是一个 HTTP 头
ord 的 JSON-API 默认就是开着的，不需要专门启动另一个进程。机制非常朴素：同一个地址，请求时带上 Accept: application/json 这个 HTTP 头，服务端就返回 JSON；不带，就返回普通网页。官方文档对这个设计的概括是，这些 JSON 对象的结构与 HTML 页面上展示的内容基本一致——也就是说，你能在页面上看到的字段，理论上都能在 JSON 里找到对应项。反过来，如果你希望自己的实例只出网页、不对外提供结构化数据，可以用 --disable-json-api 这个启动标志把接口关掉，这在把 ord server 直接暴露给公网时是一种减少被爬取压力的选择。
常用端点各自管什么
官方文档列出的端点覆盖了 ord 索引的几类核心对象。查询单个铭文用 GET /inscription/<INSCRIPTION_ID>，查最近的铭文列表用 GET /inscriptions，按区块高度查某一块里出现了哪些铭文用 GET /inscriptions/block/<BLOCKHEIGHT>；想看某个聪的当前位置与历史，用 GET /sat/<SAT>；想查一笔交易输出上挂着什么，用 GET /output/<OUTPOINT>；区块信息可以从 GET /block/<BLOCKHASH> 或 GET /block/<BLOCKHEIGHT> 拿，再配上 GET /blockcount、GET /blockhash/<BLOCKHEIGHT>、GET /blocktime 这几个辅助端点，可以把自己的对账脚本和链上高度对齐。Runes 一系也有自己的端点：GET /runes、GET /rune/<RUNE> 列表与详情各取所需。还有一类值得注意：GET /address/<ADDRESS> 能一次列出一个地址名下的所有输出和铭文，但文档明确写着它的前提是索引时加了 --index-addresses 标志——默认索引不维护地址到资产的映射，这个开关没开就会查不到。另外别忘了内容本身：铭文的原始字节按协议约定必须能从 /content/<INSCRIPTION_ID> 路径取到，这属于渲染规范而不是 JSON-API 的端点列表，两者配套使用才能完成”元数据加内容”的完整自查。
用它之前，先想清楚信的是什么
JSON-API 最大的价值不是”有接口”，而是”接口背后是你自己的节点”。当 ord 完成同步后，每一个查询都由本地索引推导，不经过任何第三方数据库；对照第三方浏览器或聚合平台的展示，两边不一致时你手上有一份可以复算的原始读数。但也正因为它读的是本地索引，索引没跟上、数据库损坏、或者版本升级后规则有调整，都会直接反映在返回结果里——把页面转成 JSON 并不会自动把数据变对。遇到字段结构和文档描述不符时，第一反应应该是核对自己跑的 ord 版本，而不是先怀疑链上数据。
操作层面的几个提醒
批量拉数据时注意分页端点的翻页参数，/inscriptions 和 /runes 都支持页码形式；GET /decode/<TRANSACTION_ID> 可以帮你把交易与信封字段对着解，调试自己写的解析器时比肉眼比对 base64 快。所有端点的完整清单和字段含义以 ord 仓库当前的 api.md 为准，这个项目迭代快，字段结构在小版本间也可能变化，脚本里最好对缺失字段做容错，而不是写死模板。
拉回来的 JSON 怎么核对
拿到 JSON 只是第一步，核对才是目的。以单个铭文为例，JSON 里给出的位置、铸造块、内容类型等字段，可以逐项与第三方浏览器的铭文页对照，也可以顺着交易哈希用普通区块浏览器把铸造交易翻一遍——两边对得上，才算把网页承诺还原成了链上事实。字段名在小版本之间有过调整的先例，脚本里与其用固定模板解析，不如按字段存在与否做分支；jq 这类工具可以直接对返回数组筛选计数，适合把一批铭文的状态压缩成一张清单。还要提醒：JSON-API 的一切都由本地索引推导，索引没同步到最新块时接口不会报错，只会给你旧状态——查询前把本地 GET /blockcount 与外部节点的高度对一遍，是成本最低的新鲜度自检。
本文为机制说明，不构成任何投资建议。铭文与资产数据的最终状态以链上记录为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。