Résumé

  • Le projet publié le 18 septembre prévoit une API v3 publique et en lecture seule, tandis que les mises à jour resteraient sur v2 au lancement.
  • La possibilité technique de lire ou de mettre en cache une réponse ne vaut pas autorisation générale de conserver, transmettre ou commercialiser les données.

Une réponse JSON peut être accessible en quelques millisecondes; cela ne répond pas à la question de savoir si un éditeur peut en faire un produit commercial. Le projet d’API v3 de PeeringDB oblige à distinguer ces deux plans.

Publié le 18 septembre comme premier appel aux commentaires, le document décrit une API publique en lecture seule, conçue pour être servie depuis plusieurs emplacements et fonctionner en parallèle de l’API actuelle, appelée v2. Les écritures resteraient sur v2 au départ. PeeringDB propose des objets plats, une synchronisation incrémentale et des instantanés quotidiens pour le chargement massif et le secours. Le but opérationnel, exposé le 21 septembre, est de réduire la latence et d’améliorer la résilience en répartissant les requêtes, puisque celles-ci sont plus nombreuses que les mises à jour.

Les objectifs de service sont déjà chiffrés: disponibilité d’au moins 99,95 %, visibilité d’au moins 99 % des changements en une minute, et plafond de fraîcheur de quinze minutes pour les réponses portant sur les données les plus récentes. Ce plafond sert à déclencher une alerte; il ne doit pas arrêter le service. Les instantanés, les parcours historiques, les miroirs tiers et le rythme de consultation du client sont exclus de cette mesure. Tous les appelants recevraient le même ensemble public; une clé API ne modifierait pas les données visibles.

La politique d’utilisation acceptable actuellement publiée traite une autre question. Elle interdit, sans autorisation préalable, de reproduire, stocker dans un système de consultation ou transmettre des données PeeringDB, sauf pour des usages opérationnels Internet approuvés. Le dépannage, le signalement d’abus et la recherche ou l’analyse sur Internet entrent dans cette catégorie; le transfert en masse exige une approbation, et la politique exclut les listes marketing, la cartographie démographique et les autres applications commerciales. Chaque demande est examinée selon l’usage déclaré.

Le projet v3 ne modifie pas cette politique. Une réponse cacheable n’est pas à elle seule un droit de constituer un entrepôt de données, encore moins de redistribuer en masse un miroir. La synchronisation delta suppose qu’un client interrogeant l’API à intervalle serré puisse maintenir une copie locale à jour; la politique précise séparément les usages permis et les autorisations nécessaires. L’exclusion des miroirs tiers des mesures de fraîcheur et des règles de retrait décrit le périmètre du service PeeringDB, pas une licence de redistribution.

La question du retrait devient concrète car l’ensemble public conserve des coordonnées précises, des notes et des contacts publiés comme publics. PeeringDB devrait annoncer une durée de conservation et proposer un retrait d’urgence pour les copies qu’il sert; les copies déjà détenues par des tiers resteraient hors de ce périmètre. Les deltas doivent signaler suppressions et retraits, mais les requêtes et réponses exactes attendent encore la spécification OpenAPI.

L’explainer du 21 septembre indique que v2 resterait d’abord l’interface de mise à jour. La retraite éventuelle de l’API actuelle et sa transition restent ouvertes à discussion. La politique d’accès, les limites de débit, le chemin v3 et plusieurs choix sur les champs et les objets ne sont pas arrêtés. Le projet indique que le comité produit devrait examiner les changements de champs et d’objets avec les contributions de la communauté; une demande dans un ticket ne garantit pas son inclusion.

Le point décisif n’est donc pas de savoir si les requêtes seront plus rapides, mais quelles copies chaque usage peut légitimement garder et partager. Le projet fournit déjà un cadre de fraîcheur ambitieux; il lui faut maintenant une frontière de réutilisation tout aussi compréhensible.

Sources