Кратко

  • Проект API v3 PeeringDB предлагает публичный сервис только для чтения с несколькими точками выдачи и целями по доступности и свежести данных.
  • Это документ для обсуждения, а не объявление о запуске: правила доступа и полная спецификация API ещё не определены, данных о работе в промышленной среде нет.

Проект задаёт временные ориентиры для будущего API, но не называет дату запуска. Документ PeeringDB от 18 сентября предусматривает доступность не ниже 99,95%, видимость 99% изменений в течение минуты и предел в 15 минут для ответов с самыми свежими данными, включая задержку кэша. Срок реализации в нём не указан. Статус документа — первая версия для комментариев и рассмотрения.

В обновлении PeeringDB, опубликованном APNIC 7 октября, объясняются причины работы. Руководитель продукта Leo Vegoda называет две цели: разделить чтение и запись, чтобы обслуживать запросы из нескольких мест, и ускорить типовые запросы к связанным объектам. Он просит пользователей API высказать мнение до реализации. Подробности находятся в проекте PeeringDB; APNIC выступает площадкой публикации, а не оператором API.

Предлагаемый первый этап намеренно ограничен. API v3 должен быть публичным и работать только на чтение параллельно с v2; запись останется в v2. Первая версия поиска охватывает имена и номера автономных систем. Частные представления или данные, зависящие от ключа, раскрытие вложенных связей, ранжированный полнотекстовый поиск и пространственные запросы или запросы по расстоянию исключены. Плоские объекты, инкрементальная синхронизация и ежедневные снимки должны помочь пользователям создавать и обновлять собственные копии. Ответы будут указывать версию набора данных, а отдельная версия API — сообщать свежесть источника.

Для целей свежести задана область измерения. Отсчёт идёт от изменения в источнике до ответа с актуальными данными; задержка кэша включается. Ежедневные снимки, исторические выборки, сторонние зеркала и интервал опроса клиента не учитываются. Порог в 15 минут служит для оповещения, а не для прекращения выдачи данных. Проект требует, чтобы пропуск цели вызывал сигнал, но не останавливал обслуживание.

Это важно операторам, которые используют PeeringDB для изучения сетей, площадок и связей с точками обмена трафиком. Проект задаёт целевой срок обновления публичного представления, но не доказывает полноту записей или точность сведений, которые ведут сами участники. PeeringDB также не является контуром управления маршрутизацией: документ не меняет распределение ресурсов RIR и решения BGP.

До реализации остаются существенные вопросы. OpenAPI должна определить синтаксис запросов, ответы, ошибки и совместимость. Политику доступа и ограничение частоты обращений также предстоит решить до начала разработки. В документе нет периода измерения доступности и срока запуска. Процент в проекте — это не журнал фактической доступности.

Следующими проверяемыми ориентирами станут обновлённая спецификация, утверждённые правила доступа и, позднее, промышленные измерения, отделяющие свежесть источника от поведения кэшей и клиентов. До этого API v3 остаётся предлагаемым контрактом будущего пути чтения, а не сервисом, на который операторы могут опираться сегодня.

Источники