要約

  • 9月18日のAPI v3初稿は、複数拠点で提供する公開読み取り専用の仕組みを提案し、当初の書き込みはv2に残す。
  • 公開APIで読めることやキャッシュできることは、データの一括保存・再配布・商用利用を認めることとは異なる。

APIが返す情報を取得できるかどうかと、その情報を製品に組み込んでよいかどうかは別問題だ。PeeringDBのAPI v3案は、読み取りの技術仕様を詳しく示す一方、利用条件の変更は宣言していない。

9月18日に公開された文書は、まだ最初の意見募集段階にある。v3は複数拠点から提供する公開の読み取り専用APIとして構想され、現行API（草案でいうv2）と並行する。初期段階の更新処理はv2に残る。データ形式を平坦にし、差分同期を用意し、日次スナップショットを大量取得や復旧の入口にする案だ。21日の説明では、読み取りが更新より多いため、両者を分ければクエリーサーバーを広く配置でき、遅延と障害耐性を改善できると説明している。

サービス目標も提示された。稼働率99.95%以上、変更の99%を1分以内に反映し、最新データの応答は15分を鮮度の上限とする。ただし15分は警報の基準であり、配信を止める条件ではない。日次スナップショット、過去データの全件走査、第三者のミラー、利用者側のポーリング間隔は鮮度測定に含まれない。APIキーの有無で公開データの範囲を変えず、全利用者に同一の公開データを返す設計でもある。

これらは配信方法の約束であって、再利用許可ではない。PeeringDBの現行利用規約は、承認済みのインターネット運用目的を除き、事前許可なしの複製、検索システムへの保存、送信を認めていない。障害対応、濫用報告、インターネットの調査・分析は運用目的に含まれる。一方、他者への一括提供には承認が必要で、マーケティング名簿や人口統計の作成、その他の商用アプリケーションは対象外とされる。申請は申告した目的に基づき個別に判断される。

草案はこの規約の改定を発表していない。応答をキャッシュできることや、5分ごとのポーリングでローカルコピーを最新に保てることが、そのまま一括保存の包括許可になるわけではない。第三者ミラーを鮮度測定や緊急削除の範囲外とする記述も、運用上どこまでをPeeringDBが測り管理するかを示すものであり、配布の許可ではない。

公開投影には公開扱いの連絡先、メモ、正確な座標も残る。PeeringDBは保持期間を公表し、自ら配信するデータを緊急削除できなければならないが、第三者がすでに持つコピーはその方針の対象外だ。差分には削除や撤回を含める要件があるものの、具体的なAPI形式を決めるOpenAPIはまだ公表されていない。

アクセス方針、レート制限、v3のパス、項目の構成やオブジェクトの選択は未決定で、実装前に詰めるとされる。草案は、製品委員会がコミュニティの意見を踏まえ項目ごとに判断することを勧めている、追跡課題に書かれた要望が初版採用を約束するわけではない。次に必要なのは、技術的に読めるデータと、利用者が保管・共有してよいデータの範囲を同じ精度で示すことだ。

出典