Visão geral da API

A tela de detalhe reúne o estado da API em um lugar: o que está publicado, o que mudou desde a última publicação, qual operação está em curso e como o runtime está respondendo. É a primeira tela a abrir quando algo não se comporta como esperado.

Estado de publicação

publish_state	Significado
DRAFT	nunca foi publicada
PUBLISHING	existe operação em andamento
ACTIVE	publicada e servindo
DEGRADED	publicada, mas o runtime diverge ou uma máquina não confirmou
FAILED	a última publicação falhou e nunca houve uma revisão ativa
ROLLING_BACK	reversão em andamento
DISABLED	desativada

O ciclo de vida (lifecycle) é outro campo: ACTIVE (operação normal), DISABLED (fora do ar; a desativação remove a API do runtime e confirma a ausência em todas as máquinas) ou ARCHIVED (valor reservado; não há operação hoje que leve uma API a ARCHIVED).

"Tenho alterações não publicadas?"

O produto compara o resumo digital (digest) da configuração atual com o da revisão ativa. Se forem diferentes, há alterações pendentes — e o campo has_unpublished_changes responde isso diretamente, junto com draft_digest e published_digest.

Isso significa que mexer numa rota, num backend ou numa política não altera o comportamento em produção: só a publicação altera.

O que o status mostra

O status da API devolve, em blocos:

Bloco	Conteúdo
publicação	ciclo de vida, estado de publicação, revisão publicada, alterações pendentes, digests, operação ativa e a última
runtime	objetos aplicados, pendências, erros e o último drift
gateway	estado do gateway para a API (active, pending, degraded, disabled, not_published), motivo e o estado de cada réplica
backends	saúde por backend, por alvo (host:porta) e por réplica
certificates	certificado de cada hostname (valid, expiring, expired, pending)
last_check	última leitura do monitor de saúde

backends vem vazio quando a API nunca foi publicada. O estado unknown de um backend tem motivo (not_configured, no_observation, warming_up, stale, partial_observation) — e é normal numa API sem tráfego: o verificador do gateway só observa os alvos depois da primeira requisição em cada réplica. O produto nunca afirma healthy sem observação real.

Motivos do bloco gateway: confirmed, confirmed_at_publish, operation_in_progress, runtime_pending, runtime_divergent, replica_unreachable, not_confirmed, api_disabled, never_published.

Indicadores de runtime que pedem atenção

Indicador	O que significa
runtime.pending maior que zero por muito tempo	objeto desejado não aplicado: reconciliador parado ou runtime recusando
runtime.errors maior que zero	há erro registrado no objeto de runtime
last_drift_at recente	alguém alterou o runtime por fora da configuração; o reconciliador corrigiu

Duas pessoas editando

Cada leitura da API devolve um ETag com o draft_version. Ao alterar, envie If-Match com o valor que você leu; se outra pessoa alterou no meio, a resposta é 412 precondition_failed e você recarrega. Sem If-Match a alteração é aplicada (última escrita vence) — use o cabeçalho em automação.

Toda alteração em rota, backend ou política incrementa o draft_version.

Onde continuar

• APIs: campos, ciclo de vida, exclusão e limites.
• Publicação: as etapas da operação e como acompanhar.
• Uso e métricas: saúde da API, métricas e uso agregado.
• Erros e diagnóstico: sintoma, primeiro suspeito e como confirmar.