# Testes em Produção (Simulação de API )

O Equinix Fabric oferece suporte a um recurso de **Teste de API** diretamente no ambiente de Produção. O recurso Dry Run permite simular com segurança chamadas de API compatíveis para verificar os dados das solicitações, a lógica de negócios e a disponibilidade de recursos **sem** provisionar qualquer infraestrutura ou incorrer em custos.

Use o recurso de Simulação (Dry Run) quando você validando novas integrações, testando alterações na automação ou confirmando que uma solicitar complexa será bem-sucedida antes de você -la "de verdade".

## Como funciona o ensaio geral[​](#como-funciona-o-ensaio-geral "Direct link to Como funciona o ensaio geral")

A execução de testes (Dry Run) é habilitada adicionando um parâmetro de consulta, como `dryRun=true`, a uma solicitação de API compatível.

Quando o parâmetro Dry Run está presente, a plataforma Fabric realiza **apenas a validação no servidor**, em vez de concluir a transação completa. Especificamente, a plataforma irá:

* **Validar entradas** – Verificar se os campos obrigatórios estão presentes e formatados corretamente, e se valores como Metros, códigos IBX, largura de banda e tipos de pacote são válidos.
* **Verificar a lógica de negócios** – Executar verificações externas e internas, como confirmar se um roteador Metro, Port ou Cloud está disponível para a operação solicitada.
* **Ignorar persistência e provisionamento** – Nenhum registro de banco de dados é criado, nenhuma ordem de serviço é gerada e nenhum recurso físico ou lógico é reservado, atualizado ou excluído.

A autenticação, autorização e verificação de quotas continuam a ser aplicadas da mesma forma que numa chamada ao vivo.

O modo de teste não ignora nenhuma permissão ou requisito de conta. Se a sua chamada de produção for rejeitada devido à falta de permissões ou a um estado de conta inválido, a chamada de teste também será rejeitada.

## Recursos e operações apoiados[​](#recursos-e-operações-apoiados "Direct link to Recursos e operações apoiados")

O recurso Dry Run está disponível para recursos e operações específicos do Fabric v4.

| **Domain / Resource** | **API Endpoint**           | **Supported Operations** |
| --------------------- | -------------------------- | ------------------------ |
| Cloud Routers         | `/fabric/v4/routers`       | Create                   |
| Connections           | `/fabric/v4/connections`   | Create, Update           |
| Networks              | `/fabric/v4/networks`      | Create                   |
| Ports                 | `/fabric/v4/ports`         | Create, Update, Delete   |
| Service Tokens        | `/fabric/v4/serviceTokens` | Create, Update           |

Para todos os outros endpoints e operações, as chamadas que incluem `dryRun=true` comportam-se como solicitações de produção padrão.

## Entendendo as respostas do ensaio geral[​](#entendendo-as-respostas-do-ensaio-geral "Direct link to Entendendo as respostas do ensaio geral")

A resposta retornada por uma simulação (Dry Run) foi projetada para espelhar de perto o que você veria em uma chamada de produção ao vivo, com algumas diferenças importantes.

### Validação bem-sucedida[​](#validação-bem-sucedida "Direct link to Validação bem-sucedida")

Se a solicitação passar em todas as verificações de validação, a API retorna **`200 OK`**.

* **Identificadores de recursos** – Campos como `uuid` ou `href` podem ser `nulos` ou omitidos, pois nenhum recurso é realmente criado durante uma simulação.
* **Números de pedido** – Não são gerados números de pedidos de compra ou outros identificadores comerciais.
* **Efeitos colaterais** – Não ocorre provisionamento, modificação ou exclusão de recursos.

Você pode usar essa resposta para confirmar se a estrutura da sua carga útil, os valores e as transições de estado solicitadas são aceitáveis ​​antes de enviar uma solicitação real sem `dryRun=true`.

### Erros de validação[​](#erros-de-validação "Direct link to Erros de validação")

Se a solicitação falhar na validação, a API retorna os **mesmos códigos de status HTTP e estruturas de erro** que uma chamada em produção retornaria (por exemplo, `400 Bad Request` para entrada inválida).

As falhas de validação típicas incluem:

* **Dados de localização inválidos** – Um código Metro ou IBX não suportado ou com erro de ortografia.
* **Transições de estado de recursos não suportadas** – Tentativa de modificar ou excluir um recurso que esteja em um estado transitório, como `PROVISIONING`.
* **Dependências não atendidas** – Por exemplo, tentar excluir uma porta que ainda possui conexões virtuais ou tokens de serviço ativos associados a ela.

Esses erros são retornados durante a execução de testes (Dry Run) sem que nenhuma alteração seja feita nos recursos de produção.

## Utilizando o Dry Run com Portas[​](#utilizando-o-dry-run-com-portas "Direct link to Utilizando o Dry Run com Portas")

O endpoint `/fabric/v4/ports` expõe um comportamento de validação avançado quando usado com o Dry Run.

### Criar Portas[​](#criar-portas "Direct link to Criar Portas")

Utilize a operação `POST /fabric/v4/ports?dryRun=true` ao enviar uma solicitação de criação de execução a seco para uma porta:

* A API valida os atributos de localização solicitados, como área metropolitana, IBX e outros.
* As propriedades do pacote e da interface (como `interfaceSpeed`, `bandwidth` e `encapsulation`) são verificadas quanto à compatibilidade e disponibilidade.
* Nenhuma porta física foi reservada e nenhum pedido foi criado.

::::observação A criação em massa de portas não é suportada pela API pública do Fabric. Cada solicitação de criação de execução de teste deve descrever uma única porta. ::::

### Atualizar Portas[​](#atualizar-portas "Direct link to Atualizar Portas")

Use a operação `PATCH /fabric/v4/ports/{uuid}?dryRun=true` para testar com segurança as alterações de configuração da porta antes de aplicá-las:

* Você pode validar atualizações nas propriedades descritivas de uma porta (por exemplo, `nome`) ou em atributos de configuração como `encapsulamento`.
* A API impõe regras de estado: tentativas de atualizar uma porta que esteja em um estado transitório (como `PROVISIONING`) retornarão um erro. A porta normalmente precisa estar no estado `ACTIVE` para a maioria das atualizações.
* As regras de dependência também são aplicadas: por exemplo, não é possível alterar o `encapsulation` se a porta tiver conexões existentes ou perfis de serviço que seriam invalidados pela alteração.

Nenhuma alteração é aplicada à Porta durante uma simulação; você recebe apenas o resultado da validação e quaisquer mensagens de erro associadas.

### Excluir Portas[​](#excluir-portas "Direct link to Excluir Portas")

Use a operação `DELETE /fabric/v4/ports/{uuid}?dryRun=true` para validar se uma solicitação de exclusão seria bem-sucedida:

* A API verifica se a porta existe e está em um estado que permite a exclusão (normalmente `ATIVA`).
* A API garante que nenhuma conexões ativa, token de serviço ou outro serviços dependente permaneça vinculado à Porta.

Caso sejam detectadas dependências, a chamada de exclusão em modo de teste (Dry Run) retorna o mesmo erro que uma solicitar de exclusão em produção retornaria, sem remover ou modificar a Porta.

## Quando usar o teste a seco[​](#quando-usar-o-teste-a-seco "Direct link to Quando usar o teste a seco")

Considere usar o modo de simulação (Dry Run) nestes cenários:

* **Antes de implementar novas automações** – Valide se as solicitações de API geradas estão estruturalmente corretas e respeitam as regras de negócios do Fabric.
* **Ao testar em produção** – Confirme se os dados reais da conta (portas, conexões, redes, roteadores em nuvem e tokens de serviço) são compatíveis com a operação pretendida antes de executá-la.
* **Para resolução de problemas** – Reproduza os cenários com falha de forma segura para entender qual regra de validação ou dependência está bloqueando uma alteração.

Após um teste bem-sucedido e quaisquer ajustes necessários, você pode reenviar a mesma solicitação sem `dryRun=true` para executar a operação real.