Gin con Go: validación y manejo de errores
Una nota práctica sobre binding JSON, DTOs y respuestas de error consistentes con Gin.
Contexto
La tercera sesión del repositorio se centra en un punto decisivo para cualquier API: no basta con recibir JSON; también hay que decidir qué datos son válidos y cómo responder cuando una petición no cumple el contrato.
El ejemplo crea POST /usuarios y valida nombre, correo y edad antes de usar
los datos enviados por el cliente.
El hallazgo
Al estructurar el handler, una diferencia pequeña terminó siendo importante:
BindJSON parece una opción directa, pero ShouldBindJSON ofrece más control
cuando se necesita una respuesta de error uniforme.
Con ShouldBindJSON el handler recibe el error y puede decidir el código HTTP,
el mensaje y la forma del JSON antes de terminar la petición. Esto evita que la
API dependa de mensajes técnicos de bajo nivel o de un formato de error
accidental.
Cómo se aplica
- Un DTO de entrada limita los campos que el cliente puede enviar.
- Las etiquetas
bindingvalidan presencia, longitud, correo y rangos. - Una petición válida responde con
201 Created. - Una petición inválida responde con
400 Bad Requesty un cuerpo JSON claro. - El handler devuelve inmediatamente después de escribir un error para evitar respuestas duplicadas.
La validación de formato no sustituye las reglas de negocio, pero funciona como la primera barrera: los datos llegan tipados y comprobados antes de que el resto de la aplicación los procese.
La guía completa y el ejemplo ejecutable están disponibles en el repositorio:
Próximo paso
Continuar la serie manteniendo el mismo criterio: ejemplos que enseñen tanto el camino correcto como las decisiones que permiten evitar errores comunes en una API.