NED 旧版 API 已弃用:如何改用新 API 访问数据
NED 旧版 API（legacy APIs）已被官方标记为弃用，且无法访问 2026 年 1 月之后收录的数据。如果你的查询涉及较新的天体、文献或红移数据，继续调用旧接口会得到不完整甚至空的结果。官方给出的替代方案是改用新版 NED API，入口在 NED 网站的 Program Interfaces 区域。下面说明如何确认自己受影响、找到新入口，以及迁移时最容易踩的坑。
先判断你是否真的受影响
旧版 API 并非立刻失效，而是存在一个明确的数据边界：
| 情况 | 旧版 API 表现 | 是否需要迁移 |
|---|---|---|
| 只查历史天体、老文献 | 通常仍能返回结果 | 可暂不迁移，但建议尽早 |
| 查询 2026 年 1 月后入库的数据 | 无法访问 | 必须迁移 |
| 依赖持续更新的红移、交叉匹配 | 结果会逐渐过时 | 必须迁移 |
判断方法很直接：用旧接口查一个你已知在 2026 年之后才被 NED 收录的天体。如果返回空或报错，说明该数据在旧接口的可见范围之外，而不是天体不存在。
新版 API 的入口在哪里
NED 网站把接口相关资源集中在 Program Interfaces 栏目下，其中包含新版 API 的说明与文档。同时网站还提供 Database Tutorials、Best Practices、Search & Retrieval FAQ 等辅助页面，迁移时遇到字段或参数疑问可以先查这些。
需要注意，网站首页明确写着旧版 API 已弃用，并直接指向新版 API。也就是说，官方并不打算长期维护两套接口并存，迁移是方向性的，不是可选项。
迁移时的关键差异
数据时间范围
这是最实质的差别。旧接口的数据快照停在 2026 年 1 月之前，新接口才能拿到之后的收录内容。NED 的数据是持续增长的，例如某次发布就新增了 22.1 万个文献来源、15.7 万个与已有天体的交叉匹配、6.3 万个新天体，并使有红移的天体增加 8.9 万个。这类增量只会进入新接口。
接口形态与调用方式
新旧 API 在请求结构、返回字段命名上通常不完全一致，不能假设把旧请求的 URL 换个域名就能用。迁移时应以新版文档为准，逐个核对：
- 查询参数名称与取值格式
- 返回结果的层级结构（例如天体基本信息、红移、交叉匹配是否分层）
- 分页或结果数量限制的处理方式
按名称、位置、参数的检索
NED 支持按名称、近名称或位置（Cone 搜索）、按 Refcode、按参数检索。迁移时确认新版接口对这些检索方式是否都提供对应端点，尤其是位置检索的坐标格式和半径单位，这类细节最容易在迁移后静默出错——请求成功但结果为空。
迁移步骤
- 确认受影响范围：列出你当前依赖的旧接口调用，标出哪些查询的是近期数据。
- 找到新版入口：在 NED 网站 Program Interfaces 区域获取新版 API 文档。
- 对照字段：用同一个天体分别请求新旧接口，逐字段比对，记录差异。
- 改写请求：按新文档调整参数名、坐标格式、返回解析逻辑。
- 验证边界：用一个 2026 年后才收录的天体测试，确认新接口能返回、旧接口返回空。
- 回归测试：对历史天体也跑一遍，确保迁移没有破坏原有查询。
常见卡点
- 以为旧接口还能用：只要查询不涉及新数据，旧接口可能看起来正常，容易误判为无需迁移。
- 坐标与单位不一致：位置检索迁移后返回空，往往不是天体不存在，而是坐标系或半径单位写错。
- 忽略交叉匹配字段：NED 大量价值来自天体间的交叉匹配，迁移时若只取主记录，会丢掉关联信息。
- 不做新旧对照：直接改写后上线，字段错位很难被发现，建议保留一段并行验证期。
小结
旧版 API 的核心限制是数据截止在 2026 年 1 月，无法获取之后的收录内容；官方替代方案是网站 Program Interfaces 下的新版 NED API。迁移的重点不在换地址，而在核对数据时间范围、请求参数和返回结构，并用新旧对照的方式验证。