摘要

  • PeeringDB API v3 草案提出一种面向多地点的公共只读服务，并列出可用性与数据更新目标。
  • 这仍是公开征求意见的设计稿：访问规则和完整 API 合约尚未定稿，也没有生产环境性能数据。

这份草案先为未来的 API 规定了时钟，却没有给出上线日期。PeeringDB 9月18日发布的文件把可用性目标设为至少 99.95%，要求 99% 的变更在一分钟内可见，并为最新数据响应设定 15 分钟的上限，缓存延迟也计入其中。文件没有说明何时实施，状态栏明确写着这是首轮征求意见与评审的草案。

APNIC 10月7日刊出的 PeeringDB 更新解释了设计缘由。产品经理 Leo Vegoda 提到两个目标：把读写分开，以便从多个地点提供读取服务；同时让常见的关联查询更高效。他邀请 API 用户在实施前反馈。详细合约载于 PeeringDB 自己的草案页；APNIC 是发布渠道，并非 API 的运营方。

提案刻意限定了第一阶段的范围。v3 将与 v2 并行，向公众提供只读访问，写操作仍留在 v2。初始搜索范围是按名称和 ASN 查找；按密钥区分的视图、嵌套展开、相关性排序的全文搜索以及空间或距离查询都不在首发范围内。扁平对象、增量同步和每日快照被设计为用户建立及更新本地副本的基础。响应将标示数据集版本，版本端点则报告源数据的新鲜度。

新鲜度数字有明确的边界：从源数据发生变化开始，计算到最新数据响应为止，缓存延迟包括在内；每日快照、历史遍历、第三方镜像和客户端自己的轮询间隔不计入。15分钟上限是告警阈值，不是停止响应的截止线。草案要求，即使错过新鲜度目标，也应发出告警而不停止服务。

对使用 PeeringDB 查看网络、设施和交换关系的运营商来说，这给未来公共数据视图提出了追赶源头的目标。但它不能证明记录完整，也不能证明参与者维护的数据准确。PeeringDB 不是路由控制平面；这份 API 设计不会改变 RIR 地址资源分配，也不会替运营商决定 BGP 路由。

实施前仍有关键部分待定。OpenAPI 规范需要明确查询语法、响应、错误和兼容规则；访问及速率限制也要在实施前确定。文件没有写出可用性目标的测量周期，也没有上线时间。设计文件中的百分比不是运行记录。

下一步值得观察的是修订后的规范、明确的访问政策，以及未来能区分源数据更新、缓存和客户端行为的生产测量。在这些证据出现前，API v3 只是未来读取路径的拟议合约，还不是运营商今天可以依赖的服务。

来源