摘要

  • 9 月 18 日的首轮征求意见稿计划让 API v3 提供多点部署的只读公开接口，同时暂时把写入留在 v2。
  • “可以公开查询、可以缓存”是技术能力，不自动构成批量保存、转售或商业再利用的授权。

接口返回数据，并不自动回答使用者能把数据带到哪里。PeeringDB 的 API v3 草案把读取性能写得很具体，却没有把公开访问改写成一张通用的数据再利用许可。

这份 9 月 18 日发布的文档仍处在首次征求意见阶段。它设想 v3 是一个只读、公开、可由多个位置提供服务的查询面，与当前的 v2 并行运行；最初的写入仍走 v2。草案还提出扁平对象、增量同步，以及用于批量初始化和故障回退的每日快照。三天后的说明把目标概括为降低查询延迟、改善韧性：大部分流量是读取，因此读写分开后，查询服务可以分布部署并支持缓存。

草案给出了三项服务指标：可用性至少 99.95%；99% 的变更在一分钟内可见；最新数据响应的时效上限为 15 分钟。这个上限是告警目标，不是停止服务的阈值。未达目标应触发告警，而不是让服务停止返回数据。快照、历史遍历、第三方镜像以及客户端自身的轮询间隔都不计入时效指标。所有调用者看到同一份公开数据，API 密钥也不会改变可见范围。

这些承诺描述的是服务怎么提供数据。PeeringDB 现行的可接受使用政策另行规定数据可以怎么用。除经 PeeringDB 批准的互联网运营用途外，未经事先许可，数据不得被复制、存入检索系统或传输。网络故障排查、滥用举报、互联网研究与分析属于政策列出的运营用途；批量交给其他组织要经过批准，营销名单、人口画像等商业应用则被明确排除。申请会按申明的用途逐案评估。

v3 草案没有宣布要修改这项政策。缓存友好的 HTTP 响应、每日快照，以及草案预期客户端每五分钟轮询以维持本地副本，是技术设计；它们本身不能回答某种用途是否获准。草案把第三方镜像排除在时效测量和紧急撤回范围之外，也只是界定服务方能测量和控制什么，不等于允许任何人复制或转发数据。

数据撤回尤其能说明边界。草案拟保留现有公开字段集，其中包括公开联系人、备注和精确坐标；PeeringDB 必须公布保留期限，并能紧急移除自己提供的副本。第三方已经持有的副本不在该政策范围内。增量同步必须呈现删除和撤回，但最终 OpenAPI 还没有定义精确的请求、响应和兼容规则。

访问方式、速率限制、v3 路径和若干字段选择仍待确定，实施前还要决定访问与速率政策。草案建议产品委员会按字段和对象分别作出决定，同时听取社区意见；某项议题出现在跟踪列表中，不代表它已被纳入首发。对依赖者而言，真正需要区分的是查询变快了多少，以及查询之后哪些保存和转发行为得到允许。

来源