Mock Condicional: Respostas Diferentes por Valor do Body

O problema: um endpoint, várias situações possíveis

Uma Mock Rule comum devolve sempre o mesmo corpo. Mas muitas integrações reais não funcionam assim — um endpoint de rastreio de contêiner, por exemplo, precisa responder "desembaraçado" para um número e "em trânsito" para outro, com o mesmo endpoint e o mesmo método. Se o seu mock só ecoa o valor recebido, ele nunca testa os ramos de decisão que o frontend (ou o time de negócio) realmente precisa validar.

Cenário real: um sistema de desembaraço aduaneiro consulta contêineres via POST /consulta, enviando um array na raiz do body (padrão comum em integrações via Kong ou gateways corporativos):

// Request de entrada
[
  { "numero": "MOLU0987651" }
]

Body array na raiz: acessando por índice

Quando o body é um array em vez de um objeto, use o índice como primeiro segmento do path — 0 para o primeiro (e geralmente único) item:

{{body '0.numero'}}
// equivalente à sintaxe legada: {{req.body.0.numero}}

Isso já resolve o eco simples — mas não ramifica a resposta por valor. Pra isso, precisamos de condicional.

Indo além do eco: casando por valor exato

O motor de templates do httpdrop é baseado em Handlebars e já registra os helpers de comparação (eq, gt, lt, gte, lte) usáveis dentro de {{#if}} — inclusive combinados com body, então você casa por qualquer campo do payload recebido, em qualquer profundidade:

// Mock Rule: POST /consulta → 200
[
  {
    "dataHora": "{{timestamp}}",
    "retorno": [
      {
        "numero": "{{body '0.numero'}}",
        "situacao": "{{#if (eq (body '0.numero') 'MOLU0987651')}}DESEMBARACADO{{else if (eq (body '0.numero') 'TCLU1234567')}}EM TRANSITO{{else}}{{faker.status}}{{/if}}",
        "localizacao": "{{faker.city}}",
        "dataAtualizacao": "{{timestamp}}"
      }
    ]
  }
]

Três chamadas com o mesmo endpoint, três respostas diferentes:

# Contêiner mapeado 1
curl -X POST https://httpdrop.com/mock/SEU_ENDPOINT_ID/consulta   -H "Content-Type: application/json"   -d '[{"numero":"MOLU0987651"}]'
# → "situacao": "DESEMBARACADO"

# Contêiner mapeado 2
curl -X POST https://httpdrop.com/mock/SEU_ENDPOINT_ID/consulta   -H "Content-Type: application/json"   -d '[{"numero":"TCLU1234567"}]'
# → "situacao": "EM TRANSITO"

# Qualquer outro número — cai no fallback
curl -X POST https://httpdrop.com/mock/SEU_ENDPOINT_ID/consulta   -H "Content-Type: application/json"   -d '[{"numero":"XXXX0000000"}]'
# → "situacao": "pending" (gerado por {{faker.status}})

Validando headers exigidos pela integração real

Specs corporativas costumam exigir headers específicos além do body — no exemplo do desembaraço, algo como access_token e jwt_token. Pra simular a mesma exigência no mock, combine o helper header com uma condicional pra devolver 401 quando faltar:

// Mock Rule: POST /consulta → 200 (com validação de header)
"{{#if (and (header 'access_token') (header 'jwt_token'))}}"
  { "dataHora": "{{timestamp}}", "retorno": ["..."] }
"{{else}}"
  { "error": "unauthorized", "message": "access_token e jwt_token são obrigatórios" }
"{{/if}}"

Na prática, é mais simples criar uma segunda Mock Rule pro mesmo path com status 401 fixo, e usar Chaos Mode ou uma condição de headers ausentes pra decidir qual delas responde — mas o padrão acima funciona direto no body quando você quer manter tudo numa regra só.

Quando o mapa de valores cresce demais

Encadear {{#if}}...{{else if}}...{{/if}} funciona bem até uns 4-5 valores mapeados. Passando disso, considere:

• Se o valor também aparece na URL (ex: /consulta/:numero), prefira Path Pattern em vez de casar no body — o motor de rotas já faz esse trabalho sem precisar de condicional.
• Se são muitas variações de dado, não de lógica (nomes, emails, valores numéricos plausíveis), use Faker em vez de mapear cada caso manualmente.
• Se o padrão se repete pra múltiplos contêineres reais capturados, o MCP tool generalize_from_traffic generaliza automaticamente a partir do histórico de requests do endpoint.