O que é Validação de entrada?

Conferir o que a aplicação recebe

Validação de entrada confere se os valores recebidos têm a presença, o tipo, o formato e os limites exigidos pela aplicação. Um campo de quantidade pode aceitar apenas inteiros positivos, enquanto uma reserva pode exigir que a data final venha depois da inicial. A verificação depende do significado de cada campo e das relações entre eles.

Em um cadastro, você pode exigir nome e email. Um campo ausente deve ser tratado de forma diferente de um campo presente com conteúdo incompatível. A resposta precisa orientar a correção conforme o contrato, sem deixar a gravação depender de valores presumidos.

As entradas chegam por formulários, APIs, arquivos importados e integrações. Por isso, validar somente a tela deixa outros pontos de entrada sem a mesma verificação. O servidor precisa conferir os valores que utilizará, independentemente de sua origem.

Sintaxe e significado

A validação sintática verifica a forma do valor. Um email pode seguir o formato esperado, e uma quantidade pode ser um número inteiro. Essas conferências não comprovam que o endereço existe ou que aquela quantidade está disponível para a reserva solicitada.

A validação semântica considera o significado no produto. Uma reserva pode exigir início anterior ao término e disponibilidade para o período. Um identificador numérico bem formado ainda precisa corresponder a um registro acessível ao perfil autenticado.

Autenticação e autorização continuam sendo verificações próprias. Um campo com formato aceito não comprova a identidade apresentada na chamada nem concede permissão para modificar o registro correspondente.

Um cadastro aceito e outro recusado

{
"erros": {
  "email": ["Preencha o email para continuar."]
}
}

O código de status e a estrutura do erro dependem do contrato da API. Esse exemplo mostra apenas um corpo possível. A interface não precisa repetir internamente a mesma implementação do servidor, mas deve apresentar uma orientação compatível com o resultado recebido.

Validar não equivale a transformar qualquer conteúdo

Uma aplicação pode normalizar um valor antes de validá-lo, como remover espaços externos quando essa transformação é permitida. O contrato precisa informar quais campos recebem esse tratamento e o que será preservado. Alterar silenciosamente um valor pode modificar o significado que você pretendia enviar.

Listas de valores aceitos são úteis para campos fechados, como uma situação com opções documentadas. Em campos de texto livre, considere os caracteres legítimos do domínio, inclusive nomes com acentos e pontuação. Uma restrição excessiva pode impedir cadastros válidos.

Validação também não substitui consultas parametrizadas no banco ou codificação adequada ao exibir conteúdo. Cada uma dessas medidas trata uma parte do processamento. Aceitar um texto não autoriza inseri-lo diretamente como código ou HTML.

Entradas aceitas, recusadas e concorrentes

Teste um formulário com o campo obrigatório preenchido e depois omitido. Confira também uma quantidade no limite permitido e outra fora dele. Em cada chamada, compare a resposta com o estado persistido, inclusive quando o envio for direto à API. Para atualizações, verifique o tratamento de um campo omitido e de outro enviado como nulo quando o contrato distingue os dois.

A exigência de email exclusivo precisa resistir a chamadas simultâneas. Duas consultas iniciais podem encontrar o mesmo endereço disponível e tentar cadastrá-lo em seguida. Uma restrição de unicidade no banco pode impedir a duplicação, e o backend precisa tratar a recusa da gravação.

Aplicação na formação

Vibe Coding: Do Zero ao MVP

A validação de entrada confere se os campos recebidos atendem às condições exigidas pela aplicação.

Conhecer a formação →