Escolher onde validar os dados não é apenas uma decisão técnica: afeta a experiência de utilização, a integridade do negócio e o custo de operar a aplicação. Apresentar um erro o mais cedo possível ajuda a preencher um formulário, mas não garante que uma operação seja válida. E transferir todas as verificações para o servidor pode proteger os dados sem evitar esperas e frustrações desnecessárias.
A decisão mais sólida consiste em atribuir cada regra à camada que a pode aplicar com a informação e a autoridade adequadas. A interface orienta; o servidor protege as regras de negócio; os processos assíncronos tratam verificações lentas ou dependentes de serviços externos. Em muitos fluxos, as três camadas colaboram.
Porque é que uma única camada raramente é suficiente
Uma validação exclusiva na interface pode ser rápida e clara, mas é possível ignorá-la ao chamar diretamente uma API, manipular o pedido ou utilizar um cliente diferente. Por isso, nunca deve ser a única barreira para uma regra que protege dados ou decisões de negócio.
No extremo oposto, validar tudo depois do envio obriga as pessoas a esperar para descobrirem erros simples, como deixar um campo obrigatório vazio ou escrever um endereço de e-mail num formato incorreto. Além disso, algumas verificações demoram mais do que um pedido normal ou dependem de sistemas que podem não estar disponíveis.
A pergunta útil não é «que camada valida os dados?», mas «que camada oferece a melhor combinação de rapidez, autoridade e contexto para cada regra». Por exemplo, uma regra de comprimento pode ser assinalada no navegador e verificada novamente no servidor. A interface melhora a interação; o servidor continua a ser quem aceita ou rejeita o dado.
Interface: feedback imediato, não autoridade final
A validação na interface permite detetar rapidamente problemas que podem ser explicados sem consultar fontes externas: campos vazios, limites de caracteres, formatos básicos ou combinações simples. Reduz tentativas falhadas e ajuda a perceber o que falta antes de enviar o formulário.
Para ser útil, a mensagem deve aparecer junto ao campo ou num resumo acessível, explicar o problema e sugerir como o corrigir. Convém evitar erros prematuros que interrompam alguém enquanto ainda está a escrever. Uma prática razoável é verificar quando a pessoa sai do campo ou envia o formulário e atualizar a mensagem quando o valor mudar.
A interface também pode antecipar limites conhecidos, como o formato esperado de uma data. No entanto, não deve considerar uma ação válida apenas porque o formulário a aceita. O navegador pode estar desatualizado, o cliente pode ser modificado e o pedido pode chegar por outra via.
- Utilize-a para feedback rápido e regras simples que facilitem o preenchimento.
- Não dependa dela para autorização, permissões, preços definitivos ou integridade dos registos.
- Indique os limites com clareza e evite mensagens que exponham informações sensíveis.
Servidor: autoridade sobre as regras de negócio
O servidor deve voltar a verificar qualquer condição cuja violação possa alterar dados, conceder acesso indevido ou levar a uma decisão incorreta. Isto inclui validar se o utilizador pode realizar a operação, se os valores pertencem ao contexto autorizado e se as transições de estado são permitidas.
A verificação deve ocorrer no ponto em que o dado é aceite ou alterado, e não apenas num ecrã específico. Se várias aplicações utilizarem a mesma API, o servidor disponibiliza uma política comum. Também deve lidar com condições de concorrência: dois pedidos podem competir pelo mesmo recurso ou tentar alterar o mesmo registo.
A validação no servidor não elimina a necessidade de mensagens compreensíveis. A resposta deve distinguir, quando for seguro fazê-lo, entre um dado mal formado, uma regra de negócio não cumprida e falta de autorização. Não convém devolver detalhes internos, consultas, rastos de execução ou informações que facilitem a exploração do sistema. As recomendações da OWASP sobre validação de entradas são uma referência útil para tratar os dados recebidos como não confiáveis.
Regra prática: se o resultado protege uma decisão ou a integridade do sistema, o servidor tem a palavra final, mesmo que a interface aplique uma verificação equivalente para reduzir a fricção.
Processos assíncronos: dependências externas e resultados tardios
Algumas regras não podem ser resolvidas com uma verificação local ou um único pedido rápido. Verificar um endereço através de um serviço externo, analisar um ficheiro ou concluir uma análise demorada pode deixar o envio inicial num estado pendente.
Nesses casos, separe a aceitação do pedido do resultado definitivo. O sistema pode confirmar que recebeu a operação e indicar que está pendente, sem afirmar que já é válida. Quando a verificação terminar, deve atualizar o estado e comunicar o resultado através de um mecanismo adequado ao produto, como uma vista de acompanhamento ou uma notificação.
Planeie também o que acontece quando algo falha: e se o serviço externo não responder, devolver um resultado inconclusivo ou recuperar após uma interrupção? Defina limites de espera, novas tentativas razoáveis e uma forma de revisão ou recuperação. Um tempo limite não demonstra que o dado é inválido; pode significar que não foi possível concluir a verificação.
Se o resultado puder chegar depois de o utilizador sair do ecrã, o estado deve continuar disponível para consulta. Evite que uma resposta tardia substitua uma alteração mais recente: associe o resultado à operação ou versão que foi verificada.
Decidir onde aplicar cada regra
Avalie cada validação com quatro perguntas: quanto custa um erro?, de que informação precisa?, quanto tempo demora a estar disponível? e quem tem autoridade para decidir? Estas perguntas ajudam a separar regras que muitas vezes aparecem misturadas num único formulário.
- Experiência: se a verificação for simples e o erro puder ser corrigido de imediato, mostre-a na interface.
- Segurança e integridade: se afetar permissões, dados persistidos ou uma decisão financeira, aplique-a no servidor.
- Dependências e latência: se exigir serviços remotos ou uma análise demorada, represente um estado pendente e trate o resultado mais tarde.
- Custo do erro: quanto maior for o impacto de aceitar um valor incorreto, mais controlos e rastreabilidade serão necessários.
Uma regra pode exigir mais do que uma camada, mas nem todas têm de a resolver com o mesmo nível de detalhe. Uma interface pode verificar se um campo não está vazio; o servidor pode também aplicar restrições de contexto e permissões. A redundância é útil quando cada verificação tem um propósito claro.
Coerência sem duplicar regras de forma divergente
O risco de repetir uma regra é que ela mude numa camada e não noutra. A interface pode aceitar um valor que o servidor rejeita, ou bloquear um valor que já é válido. Para reduzir estas divergências, defina as regras de negócio com uma fonte de verdade identificável e mantenha contratos claros entre o cliente e a API.
Quando a arquitetura o permitir, é possível partilhar esquemas ou componentes de validação entre o cliente e o servidor. Isso não transforma o cliente numa autoridade: o servidor tem de executar a verificação no seu próprio limite de confiança. Se não for viável partilhar a implementação, documente critérios, casos-limite e respostas esperadas, e acrescente testes para ambos os lados.
Preste especial atenção às regras que mudam com o tempo ou dependem do utilizador, da região, do estado de uma conta ou da disponibilidade de um recurso. Não codifique na interface, como valores constantes, decisões que o servidor pode atualizar. Se forem enviadas ao cliente restrições informativas, trate-as como orientações que podem estar desatualizadas.
Erros que indicam o que fazer a seguir
Um erro acionável identifica o dado afetado, explica o motivo sem jargão e propõe um passo seguinte. Se puder ser corrigido antes do envio, associe-o ao campo. Se a operação já estiver em curso, explique o estado geral e como consultar ou repetir a ação. Para evitar duplicados numa nova tentativa, o desenho deve prever o que acontece se o primeiro pedido tiver sido concluído, mas a resposta não tiver chegado ao cliente.
Não utilize uma mensagem de campo para uma condição que dependa do estado global do processo. Por exemplo, se um recurso deixar de estar disponível, é preciso explicar a alteração e apresentar alternativas, em vez de apenas assinalar o formato do campo como incorreto. Se não for seguro revelar o motivo exato, dê uma explicação neutra e indique um canal para continuar.
Lista de verificação antes do lançamento
- Enumere as regras e identifique quais dizem respeito a formato, negócio, autorização ou dependências externas.
- Confirme que todas as regras críticas são verificadas no servidor antes de aceitar a alteração.
- Verifique se as mensagens da interface são oportunas, acessíveis e permitem corrigir o problema.
- Defina estados pendentes, falhas temporárias, novas tentativas e respostas tardias.
- Teste pedidos diretos à API, valores-limite, permissões e alterações concorrentes.
- Confirme que os erros não expõem dados internos e indicam o passo seguinte.
- Atribua responsáveis pela atualização das regras partilhadas quando o produto mudar.
O melhor desenho não valida tudo em todo o lado nem espera sempre pelo servidor. Combine feedback antecipado com uma autoridade clara e uma gestão explícita das verificações tardias. Assim, a aplicação torna-se mais compreensível para quem a utiliza e mais resistente a dados inválidos, mudanças de contexto e falhas de dependências.