Elegir dónde validar los datos no es solo una decisión técnica: afecta a la experiencia de uso, la integridad del negocio y el coste de operar la aplicación. Mostrar un error cuanto antes ayuda a completar un formulario, pero no garantiza que una operación sea válida. Y trasladar todas las comprobaciones al servidor puede proteger los datos sin evitar esperas y frustración innecesarias.
La decisión más sólida consiste en asignar cada regla a la capa que puede aplicarla con la información y la autoridad adecuadas. La interfaz orienta; el servidor protege las reglas de negocio; los procesos asíncronos resuelven comprobaciones lentas o dependientes de servicios externos. En muchos flujos, las tres capas colaboran.
Por qué una sola capa no suele ser suficiente
Una validación exclusiva en la interfaz puede ser rápida y clara, pero es posible omitirla al llamar directamente a una API, manipular la solicitud o utilizar un cliente distinto. Por eso, nunca debe ser la única barrera para una regla que protege datos o decisiones de negocio.
En el extremo contrario, validar todo después del envío obliga a las personas a esperar para descubrir errores sencillos, como dejar vacío un campo obligatorio o escribir un correo con un formato incorrecto. Además, algunas comprobaciones tardan más que una petición normal o dependen de sistemas que pueden no estar disponibles.
La pregunta útil no es «¿qué capa valida los datos?», sino «qué capa ofrece la mejor combinación de rapidez, autoridad y contexto para cada regla». Por ejemplo, una regla de longitud puede señalarse en el navegador y volver a comprobarse en el servidor. La interfaz mejora la interacción; el servidor sigue siendo quien acepta o rechaza el dato.
Interfaz: feedback inmediato, no autoridad final
La validación en la interfaz sirve para detectar pronto problemas que se pueden explicar sin consultar fuentes externas: campos vacíos, límites de caracteres, formatos básicos o combinaciones simples. Reduce intentos fallidos y ayuda a entender qué falta antes de enviar el formulario.
Para que sea útil, el mensaje debe aparecer junto al campo o en un resumen accesible, explicar el problema y sugerir cómo corregirlo. Conviene evitar errores prematuros que interrumpan mientras alguien todavía está escribiendo. Una práctica razonable es comprobar al salir del campo o al enviar, y actualizar el mensaje cuando cambie el valor.
La interfaz también puede anticipar límites conocidos, como el formato esperado de una fecha. Sin embargo, no debe dar por válida una acción solo porque el formulario la acepta. El navegador puede estar desactualizado, el cliente puede modificarse y la solicitud puede llegar por otra vía.
- Úsala para comentarios rápidos y reglas sencillas que mejoran la captura.
- No dependas de ella para autorización, permisos, precios definitivos o integridad de registros.
- Indica límites con claridad y evita mensajes que expongan información sensible.
Servidor: autoridad sobre las reglas del negocio
El servidor debe volver a comprobar cualquier condición cuya infracción pueda alterar datos, conceder acceso indebido o producir una decisión incorrecta. Esto incluye validar que el usuario puede realizar la operación, que los valores pertenecen al contexto autorizado y que las transiciones de estado están permitidas.
La comprobación debe ocurrir en el punto donde se acepta o modifica el dato, no solo en una pantalla concreta. Si varias aplicaciones consumen la misma API, el servidor ofrece una política común. También debe manejar las condiciones de concurrencia: dos solicitudes pueden competir por un recurso o intentar cambiar el mismo registro.
La validación del servidor no elimina la necesidad de mensajes comprensibles. La respuesta debe distinguir, cuando sea seguro hacerlo, entre un dato mal formado, una regla de negocio incumplida y una falta de autorización. No conviene devolver detalles internos, consultas, trazas o información que ayude a explotar el sistema. Las recomendaciones de OWASP sobre validación de entradas son una referencia útil para tratar los datos recibidos como no confiables.
Regla práctica: si el resultado protege una decisión o la integridad del sistema, el servidor tiene la última palabra, aunque la interfaz aplique una comprobación equivalente para ahorrar fricción.
Procesos asíncronos: dependencias externas y resultados tardíos
Algunas reglas no se pueden resolver con una comprobación local o una única petición rápida. Verificar una dirección con un servicio externo, analizar un archivo o completar una revisión que requiere tiempo puede dejar el envío inicial en un estado pendiente.
En esos casos, separa la aceptación de la solicitud del resultado definitivo. El sistema puede confirmar que recibió la operación y comunicar que está pendiente, sin afirmar que ya es válida. Cuando termina la comprobación, debe actualizar el estado y notificar el resultado por un mecanismo adecuado al producto, como una vista de seguimiento o un aviso.
Diseña también el camino de fallo: ¿qué ocurre si el servicio externo no responde, devuelve un resultado inconcluso o se recupera tras un corte? Define límites de espera, reintentos razonables y una forma de revisión o recuperación. Un tiempo de espera no demuestra que el dato sea inválido; puede significar que la comprobación no pudo completarse.
Si el resultado puede llegar después de que el usuario haya abandonado la pantalla, el estado debe seguir siendo consultable. Evita que una respuesta tardía sobrescriba un cambio más reciente: asocia el resultado con la operación o versión que se comprobó.
Decidir dónde vive cada regla
Evalúa cada validación con cuatro preguntas: ¿cuánto cuesta equivocarse?, ¿qué información necesita?, ¿cuánto tarda en estar disponible? y ¿quién tiene autoridad para decidir? Estas preguntas ayudan a separar reglas que a menudo se mezclan en un único formulario.
- Experiencia: si una comprobación es simple y el error puede corregirse al instante, muéstrala en la interfaz.
- Seguridad e integridad: si afecta a permisos, datos persistidos o una decisión económica, aplícala en el servidor.
- Dependencias y latencia: si requiere servicios remotos o un análisis prolongado, representa un estado pendiente y gestiona el resultado después.
- Coste de error: cuanto mayor sea el impacto de aceptar un valor incorrecto, más controles y trazabilidad hacen falta.
Una regla puede necesitar más de una capa, pero no todas las capas tienen que resolverla con idéntico detalle. Una interfaz puede comprobar que un campo no está vacío; el servidor puede aplicar además restricciones de contexto y permisos. La redundancia es útil cuando cada comprobación tiene un propósito claro.
Coherencia sin duplicar reglas de forma divergente
El riesgo de repetir una regla es que cambie en una capa y no en otra. La interfaz podría aceptar un valor que el servidor rechaza, o bloquear uno que ya es válido. Para reducir estas divergencias, define las reglas de negocio con una fuente de verdad identificable y mantén contratos claros entre cliente y API.
Cuando la arquitectura lo permita, se pueden compartir esquemas o componentes de validación entre cliente y servidor. Eso no convierte al cliente en autoridad: el servidor debe ejecutar la comprobación en su propio límite de confianza. Si compartir implementación no es viable, documenta criterios, casos límite y respuestas esperadas, y añade pruebas para ambos lados.
Presta especial atención a reglas que cambian con el tiempo o dependen del usuario, la región, el estado de una cuenta o la disponibilidad de un recurso. No codifiques como constantes en la interfaz decisiones que el servidor puede actualizar. Si se envían al cliente restricciones informativas, trátalas como una guía que puede haber quedado obsoleta.
Errores que indican qué hacer a continuación
Un error accionable identifica el dato afectado, explica el motivo sin jerga y propone un siguiente paso. Si puede corregirse antes del envío, asócialo al campo. Si la operación ya está en curso, explica el estado general y cómo consultar o repetir la acción. Para evitar duplicados al reintentar, el diseño debe contemplar qué sucede si la primera solicitud se completó pero su respuesta no llegó al cliente.
No uses un mensaje de campo para una condición que depende del estado global del proceso. Por ejemplo, un recurso que dejó de estar disponible requiere explicar el cambio y ofrecer alternativas, no solo marcar el formato del campo como incorrecto. Si no es seguro revelar la causa exacta, ofrece una explicación neutral y un canal para continuar.
Lista de comprobación antes del lanzamiento
- Enumera las reglas y señala cuáles son de formato, negocio, autorización o dependencia externa.
- Confirma que toda regla crítica se comprueba en el servidor antes de aceptar el cambio.
- Revisa que los mensajes de interfaz sean oportunos, accesibles y corregibles.
- Define estados pendientes, fallos temporales, reintentos y respuestas tardías.
- Prueba solicitudes directas a la API, valores límite, permisos y cambios concurrentes.
- Comprueba que los errores no exponen datos internos y que indican el siguiente paso.
- Asigna responsables para actualizar reglas compartidas cuando cambie el producto.
El mejor diseño no valida todo en todas partes ni espera siempre al servidor. Combina feedback temprano con una autoridad clara y una gestión explícita de las comprobaciones tardías. Así la aplicación resulta más comprensible para quien la usa y más resistente ante datos inválidos, cambios de contexto y fallos de dependencias.