Resumo

  • A página da API de Registro da LACNIC diz que a documentação v3 mais atual está no Postman, mas sua tabela local ainda apresenta alteração e remoção de ROA em /rpki/roas/{serialNumber}.
  • Na coleção vinculada, GET, criação e atualização usam organizationId; o PUT substitui a lista existente por uma versão atualizada, e a revogação também recebe uma lista no escopo da organização.
  • O estado desejado completo pode ser atômico e idempotente. Para que também seja auditável, o contrato público deve vincular a lista a uma base, mostrar o diff, permitir preflight e devolver uma identidade de operação e correção.

Quem abre a página da API de Registro da LACNIC recebe uma orientação direta: a versão mais atual da documentação v3 está no Postman. A rota /lacnic/v3/info reforça essa escolha ao redirecionar para o mesmo documento publicado. Um desenvolvedor tem bons motivos para tratar a coleção como contrato de implementação.

Na própria página, porém, a tabela apresenta outro desenho. Criar e consultar ROAs ocorre em /rpki/roas. Modificar e remover ocorre em /rpki/roas/{serialNumber}. O número de série delimita um objeto; a solicitação diz respeito àquela autorização.

A coleção API Registro v3 Prod trabalha com o conjunto. GET e POST usam /lacnic/v3/rpki/roas/{organizationId}. O PUT segue o mesmo caminho e é descrito como substituição da lista existente por uma versão atualizada. Para revogar, o cliente envia uma lista por POST a /lacnic/v3/rpki/roas-delete/{organizationId}.

Essa mudança de unidade é maior que a diferença entre duas rotas. Na tabela, a intenção é editar um ROA. Na coleção, a intenção é declarar quais ROAs devem compor o estado final da organização.

O caso mais forte a favor do conjunto

Há elegância operacional na segunda abordagem. O cliente lê tudo, compara com sua fonte de intenção e envia o estado final em uma única operação. O servidor pode validar o conjunto inteiro e fazer uma troca atômica. Uma cadeia de chamadas individuais, ao contrário, pode parar no meio e deixar metade das alterações aplicada.

Também há uma vantagem de repetição. Se o cliente perder a resposta após um PUT, o mesmo payload pode convergir de novo para o mesmo estado. Esse comportamento combina com IPAM, rotinas de reconciliação e automação de segurança de roteamento. Declarar o resultado desejado costuma ser mais simples do que programar a sequência interna de cada inclusão e retirada.

Nada no material coletado prova que a LACNIC deixe de proteger escritas concorrentes. O serviço pode serializar operações por organização, comparar revisões internas, rejeitar listas antigas, manter histórico protegido ou oferecer uma tela autenticada com diferenças. Nenhuma credencial foi usada nesta pesquisa. Nenhum ROA foi criado, modificado ou revogado.

A conclusão deve permanecer no plano documental: o exemplo público de lista completa não revela a condição que liga o estado enviado ao estado lido.

Quando o que não veio no JSON vira decisão

Em uma edição por número de série, os demais objetos não participam da operação. Em uma substituição completa, cada ausência pode significar retirada. O cliente precisa distinguir «quero remover» de «não conhecia esta entrada».

Considere duas ferramentas autorizadas. Uma lê a lista para incluir um novo prefixo. Outra havia lido antes para ajustar o maxLength de uma autorização diferente. As duas montam listas completas e coerentes com suas respectivas leituras. Se a inclusão for gravada primeiro e o ajuste chegar depois com uma base antiga, qual regra prevalece?

O servidor pode rejeitar a segunda lista, exigir nova leitura, fazer merge controlado ou aceitar a última representação. Todas são escolhas de implementação. Nos campos públicos verificados não aparecem ETag, If-Match, token de revisão, hash da lista de base ou precondição equivalente. Também não aparecem dry-run, preview ou diff. O exemplo de atualização não publica cabeçalhos nem corpo de resposta.

Isso não é evidência de que uma atualização tenha sido perdida. É evidência de que o integrador não encontra no contrato aberto como uma atualização obsoleta seria identificada. A diferença entre essas duas afirmações protege a precisão da análise.

O cuidado é necessário porque um ROA não é uma linha decorativa. O perfil atual em RFC 9582 associa recursos IP a um AS de origem e pode incluir o comprimento máximo. RFC 9319 mostra como maxLength afeta a cobertura de anúncios mais específicos.

Acrescentar, restringir ou omitir uma autorização altera a evidência usada na validação de origem. A LACNIC não controla a política de cada rede, nem uma resposta da API prova o que um roteador aceitou. O ponto de controle é anterior: o registro deve provar qual transição aceitou em nome da organização.

Uma só definição para tabela, redirecionamento e coleção

O primeiro passo é gerar as três superfícies a partir de uma definição versionada. Se a atualização atual é uma substituição de lista por organização, a tabela resumida deve usar esse vocabulário. Se a rota por serialNumber continua válida, o texto precisa dizer se ela altera um item, se é compatibilidade ou se o servidor a converte em operação de conjunto.

O Postman registra uma data de publicação em junho de 2023, não uma última atualização verificada. A coleta acessou a etiqueta ativa latest. A autoridade não deve depender de adivinhar qual data parece mais nova. O mesmo identificador de contrato deve estar visível em todos os pontos.

O segundo passo é entregar uma identidade de base no GET: ETag, revisão opaca ou hash canônico. O PUT passa a afirmar que a substituição só vale se a lista atual ainda for aquela. Caso contrário, a API devolve conflito e garante que nada mudou.

O terceiro passo é oferecer preflight. Antes da escrita, o serviço mostra inclusões, mudanças e remoções, inclusive prefixo, AS de origem e maxLength. Uma entrada perdida por serialização incompleta aparece como remoção e pode ser corrigida antes de afetar o estado registrado.

O quarto passo é registrar o desfecho. Um identificador de operação une versão do contrato, base aceita, estado resultante e resultado atômico. Se a resposta sumir, o cliente consulta essa identidade. Se houver correção, a nova operação aponta para a anterior em vez de reescrever a explicação.

Peça do contrato Limite que esclarece
Versão de rota e esquema Qual semântica de escrita estava em vigor
Organização e identidade da base Qual estado o cliente realmente viu
Diff de inclusão, mudança e remoção Qual efeito a lista completa pretendia produzir
Preflight Se validação e obsolescência foram detectadas antes da mutação
Operação e resultado atômicos Se a transição foi aceita, rejeitada ou apenas consultada novamente
Elo de correção Qual decisão posterior substituiu a anterior

Esse comprovante não precisa divulgar nome de usuário, chave, mecanismo antifraude ou log interno. A garantia e o esquema devem ser públicos; o detalhe da organização pode permanecer acessível apenas às partes autorizadas. A transparência necessária é sobre o ato do sistema, não sobre toda a vida privada da conta.

A LACNIC já ensina a criar e corrigir ROAs e oferece uma API para tornar o trabalho repetível. A lacuna está entre o índice e a execução. Se o Postman é o contrato atual, o resumo não deveria conservar outra fronteira. Se o conjunto é a fronteira atual, cada substituição deveria dizer qual conjunto conhecia antes de falar em nome do todo.

Fontes