Configurações do serviço

Atualizado em 29 de set. de 2026·6 min de leitura

Cada serviço de uma simulação tem as próprias configurações: para onde ele faz proxy, o que ele guarda em cache, o que ele valida, e como o spec dele é servido. Elas ficam em Configuração do serviço, na barra lateral.

Uma página por serviço

A página configura um serviço por vez. Escolha ele no seletor de cima; o ícone diz se ele é um conjunto de endpoints estáticos ou um spec OpenAPI.

A página Configuração do serviço com o seletor aberto, listando três serviços estáticos e o serviço de OpenAPI petstore — O seletor de serviços na página Configuração do serviço

Os dois tipos dividem quase toda esta página. Upstream, Cache e YAML valem para todo serviço; Validação e Opções do spec existem só para os serviços de OpenAPI, porque os dois precisam de um spec para trabalhar em cima. Um serviço estático também não tem montagem para editar: o prefixo dele vem do primeiro segmento de caminho dos endpoints.

O menu do canto cuida do serviço em si: Substituir arquivo troca o spec, Voltar para a versão do catálogo restaura um spec do catálogo, e Excluir serviço remove ele. Excluir um serviço estático apaga todo endpoint sob o prefixo dele.

Tudo nesta página é salvo enquanto você digita e vale no próximo deploy.

Caminho de montagem

Ao lado do seletor, um serviço de OpenAPI mostra a montagem dele como /<montagem>/*, editável ali mesmo. Letras minúsculas, dígitos, -, _ e /, sem barra no começo nem no fim, até 32 caracteres; uma montagem que outro serviço já tem é recusada. Mudar ela move todo endpoint do serviço para o prefixo novo, então quem chama tem que acompanhar.

Upstream

Ligue Fazer proxy para um upstream e as requisições chegam primeiro no seu backend de verdade; a simulação só responde quando o backend não responde.

Quem responde o quê:

O upstream responde com sucesso: a resposta dele volta para quem chamou, sem mudança.
O upstream não é alcançado, estoura o tempo, ou devolve um status de erro: o mock gerado responde no lugar.
Os status que casam com Falhar conforme o status do upstream pulam a queda para o mock e chegam a quem chamou como estão. O padrão é 400-499 menos 401 e 403: a sua própria requisição errada fica visível, enquanto uma credencial faltando cai no mock. Corresponder pelo corpo da resposta afina uma regra para os backends que colocam os códigos de erro dentro do corpo.

Toda resposta diz de onde veio: o header X-Mockzilla-Source traz upstream, generated, cache ou replay.

Os Headers adicionados entram em toda requisição enviada pelo proxy; um token de autenticação ou um id de tenant vai aqui e não em cada cliente.

O Roteamento sticky do upstream ajuda quando a queda para o mock aconteceu no meio de um fluxo: depois que um cliente recebe uma resposta gerada, as requisições seguintes dele vão direto para os mocks pelo tempo indicado, para uma requisição não misturar estado real com estado gerado.

O Timeout é quanto esperar pelo backend, 5s se você não mudar.

A requisição inteira roda dentro do timeout de requisição do seu plano. Mantenha o timeout do upstream abaixo dele: um backend que consome a janela toda faz a requisição ser cortada antes de o mock conseguir responder.

O upstream configurado aqui vale para o serviço inteiro. Um endpoint sozinho pode sobrescrever com outra URL, pela aba Upstream do painel dele; todo o resto continua usando o upstream do serviço.

Veja Endpoints e respostas estáticas.

Cache

Guardar respostas de GET em cache devolve de novo a primeira resposta nas requisições GET repetidas, em vez de gerar ou buscar outra vez. Só requisições GET vão para o cache, e nas repetições a resposta em cache ganha do upstream. Ligue quando quem consome repete a busca e o dado mudar só seria ruído.

Validação

Um spec OpenAPI é um contrato, e a aba Validação faz a simulação cobrar ele.

Validar requisições confere os corpos que chegam e os parâmetros de consulta e de caminho contra o spec. Uma requisição que não bate recebe um 400 com detalhes e nunca chega no upstream. É esta que vale ligar enquanto você constrói um cliente: o mock te avisa de uma chamada mal formada na hora em que você faz ela.
Validar respostas confere as respostas na saída; uma resposta que não bate com o spec vira um 500 com detalhes. Para as respostas geradas quase nunca é preciso. Ela se paga com um upstream: toda resposta de verdade é conferida contra o spec, o que transforma a simulação em um teste de contrato do serviço de trás. Também pega um valor de contexto que quebra o schema que ele preenche.
Detalhes de erro estendidos coloca o schema de referência inteiro nos payloads de erro; por padrão eles vão enxutos.
Timeout de validação limita uma chamada de validação, um segundo se você não mudar, para um schema patológico não travar as requisições.

Opções do spec

Estas opções controlam como o spec é carregado e servido. Elas importam principalmente para os specs muito grandes.

Carregar operações sob demanda analisa cada operação na primeira requisição dela em vez de todas na inicialização. Subida mais rápida para os specs grandes, pouca diferença para os pequenos.
Simplificar o schema corta os schemas exagerados, descartando os ramos anyOf/oneOf/allOf a mais. Ligar ele mostra o Limitar propriedades opcionais: quantos campos opcionais as respostas geradas mantêm. Mínimo e máximo iguais dão uma quantidade exata; uma faixa escolhe ao acaso dentro dela.

Veja Subir e atualizar um spec OpenAPI para saber quando um spec pesa o bastante para precisar delas.

A aba YAML

A mesma configuração das outras abas, mostrada no YAML cru do motor. Por enquanto é só leitura; use para ver exatamente o que a simulação publicada vai receber.