Кратко

  • Страница регистрационного API LACNIC отправляет в Postman за наиболее актуальной документацией v3, хотя её собственная таблица описывает изменение и удаление ROA по адресу /rpki/roas/{serialNumber}.
  • В опубликованной коллекции GET, создание и PUT работают в границах organizationId; PUT заменяет существующий список обновлённой версией, а отзыв также принимает список организации.
  • Полное желаемое состояние может быть атомарным и идемпотентным. Для проверяемости ему нужны идентификатор базы, предполагаемая разница, предварительная проверка, единый результат операции и связь исправлений.

У страницы регистрационного API LACNIC есть ясная навигационная функция. Она говорит, что наиболее актуальная документация версии 3 находится в Postman. Производственный путь /lacnic/v3/info тоже перенаправляет к тому же опубликованному документу. Разработчик нового клиента должен считать эту коллекцию действующим публичным контрактом.

Но таблица на входной странице задаёт другую модель. Создание и получение находятся в /rpki/roas, изменение и удаление — в /rpki/roas/{serialNumber}. Серийный номер выделяет один объект. Остальные записи организации не входят в выраженное намерение.

В API Registro v3 Prod границей становится организация. GET и POST используют /lacnic/v3/rpki/roas/{organizationId}. PUT идёт по тому же адресу и описан как замена существующего списка обновлённой версией. Для отзыва список отправляется в /lacnic/v3/rpki/roas-delete/{organizationId}.

Это не просто два варианта маршрута. В первом случае изменяется элемент. Во втором клиент заявляет итоговое состояние всего множества, а отсутствие элемента может стать распоряжением об удалении.

Почему замена списка может быть правильной

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

Полный список упрощает повтор. Если сервер выполнил PUT, но ответ потерялся, тот же payload может снова привести к тому же состоянию. Для IPAM, регулярной сверки и инструментов маршрутной безопасности такое схождение часто проще, чем журнал мелких команд.

У LACNIC могут существовать меры, не показанные в публичном примере. Сервис может сериализовать запись организации, сравнивать внутреннюю ревизию, отклонять устаревший список, хранить защищённую историю или показывать разницу после входа. В исследовании не использовались учётные данные, не создавались, не менялись и не отзывались ROA.

Поэтому вывод ограничен документацией: открытый контракт не показывает, как полный список привязан к прочитанному состоянию.

В полном состоянии пропуск становится действием

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

Первый процесс записывает добавление. Затем второй отправляет старую картину мира. Сервер может отклонить устаревшую базу, потребовать повторное чтение, объединить изменения по определённому правилу или принять последний список целиком. Проверенные публичные примеры не называют выбранное поведение.

В полях запросов и ответов не найдено ETag, If-Match, токена ревизии, хеша базового списка или иной видимой предпосылки. Нет dry-run, preview или предполагаемого diff. Пример GET возвращает массив и показывает только Content-Type; пример обновления не содержит опубликованных заголовков или тела ответа.

Это не доказательство потерянного обновления. Это доказательство того, что интегратор не узнает из открытого примера, как будет обработана устаревшая замена. Внутренняя защита может быть сильной, оставаясь невидимой снаружи.

Содержимое списка имеет операционный смысл. RFC 9582 определяет актуальный профиль ROA, связывающий IP-ресурсы с origin AS и допускающий максимальную длину. RFC 9319 показывает, почему maxLength меняет охват более специфичных объявлений.

Добавление, сужение или выпадение ROA меняет доказательства, с которыми работает валидация происхождения. Это не означает, что LACNIC управляет решениями маршрутизатора. Публикация, получение валидатором и политика сети — отдельные поверхности. Регистрационный API должен точно доказать лишь собственный принятый переход.

Один исполняемый источник для трёх поверхностей

Сначала таблица сайта, цель /info и коллекция должны формироваться из одного версионированного определения. Если актуальная операция заменяет список организации, краткая таблица обязана это сказать. Если путь по serialNumber всё ещё поддерживается, нужно объяснить, является ли он индивидуальным изменением, совместимостью или преобразованием в операцию над множеством.

В метаданных Postman есть дата публикации в июне 2023 года, но она не подтверждена как дата последнего изменения. Коллекция была получена по активному тегу latest. Оператору не следует выбирать авторитетную версию по догадке о датах; один идентификатор контракта должен присутствовать везде.

Далее GET возвращает идентификатор базы: ETag, непрозрачную ревизию или канонический хеш. PUT означает: заменить только при условии, что текущий список всё ещё совпадает с прочитанной базой. Иначе конфликт гарантирует отсутствие мутации.

Предварительная проверка показывает добавления, изменения и удаления, включая префикс, origin AS и maxLength. Элемент, исчезнувший из-за неполной сериализации, становится видимым удалением до записи. Там же обнаруживаются ошибки проверки и устаревшая база.

Наконец, попытка получает единый идентификатор операции. Он связывает версию контракта, принятую базу, итоговую идентичность и атомарный исход. После таймаута клиент проверяет исход по тому же ID. Исправление ссылается на заменённую операцию и не стирает её происхождение.

Элемент Закрываемый вопрос
Версия пути и схемы Какая семантика записи действовала?
Организация и ID базы Какое состояние видел клиент?
Diff добавлений, изменений и удалений Что означал полный список?
Preflight Были ли ошибка и устаревание остановлены до записи?
Атомарная операция и результат Был ли переход принят, отклонён или повторно проверен?
Ссылка исправления Какое решение было заменено позднее?

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

LACNIC помогает создавать и исправлять ROA и переводит обслуживание в автоматизированную форму. Именно поэтому единица записи должна быть однозначной. Если Postman является текущим контрактом, указатель не должен описывать другой объект. Если объектом является список, он должен доказать, какую версию знает, прежде чем заменить целое.

Источники