Validação de métodos HTTP com TypeScript e Zod

No desenvolvimento de APIs ou integrações, garantir que os parâmetros estejam alinhados com os tipos esperados do Axios é essencial para evitar bugs em produção.

Recentemente, me deparei com uma dúvida parecida: como criar um schema com Zod que valide se um valor é compatível com o tipo Method do Axios? É uma questão prática que mostra como integrar validações de tipos do TypeScript com validações de runtime.

O tipo Method do Axios inclui valores como 'get', 'post', 'put', entre outros, além de variações em maiúsculas. Para validar isso com Zod, uma abordagem possível é criar uma lista de valores permitidos e usar zod.enum() ou zod.union(). Sem esse critério, a solução pode parecer simples no começo e cara no suporte.

Por exemplo:

const methodSchema = zod.union([
  zod.literal('get'),
  zod.literal('GET'),
  zod.literal('delete'),
  zod.literal('DELETE'),
  // acrescentar outros métodos conforme necessário
]). 

Ou, de forma mais direta, usar zod.enum() se preferir uma lista fixa. Essa estratégia ajuda a garantir que o parâmetro enviado na requisição seja um método válido, reduzindo erros na integração. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois.

A questão que fica é: você já precisou fazer validações assim em outros tipos do Axios ou em APIs específicas? Como vocês lidam com essa validação de runtime e tipagem no dia a dia? Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.

Vamos trocar umas ideias sobre melhores práticas de validação de tipos em TypeScript para APIs.