Validadores de cuerpo de solicitud

La validación de entrada es la primera línea de defensa en cualquier aplicación web. Los datos inválidos causan fallos, corrompen bases de datos, habilitan ataques de inyección y crean errores sutiles que se manifiestan en producción semanas después del despliegue. Sin embargo, en la mayoría de los frameworks, la validación es código tardío disperso en los handlers, duplicado entre endpoints e inconsistentemente aplicado.

Los bloques validate de FLIN son declarativos, componibles y aplicados antes de que se ejecute el código del handler. Se declara cómo debe verse el cuerpo de la solicitud, y FLIN rechaza automáticamente las solicitudes malformadas con respuestas de error estructuradas. Sin biblioteca de validación. Sin verificación manual. Sin forma de olvidarla.

El bloque validate

Un bloque validate declara la forma esperada y las restricciones del cuerpo de la solicitud:

flinroute POST {
    validate {
        name: text @required @minLength(2) @maxLength(100)
        email: text @required @email
        age: int @min(13) @max(120)
        role: text @one_of("user", "admin", "moderator")
        bio: text @maxLength(500)
    }

    // Si llegamos aquí, todas las validaciones pasaron
    // body.name está garantizado como cadena de 2-100 caracteres
    // body.email está garantizado como email válido
    // body.age está garantizado como entero entre 13 y 120

    user = User {
        name: body.name,
        email: body.email,
        age: body.age,
        role: body.role || "user",
        bio: body.bio || ""
    }
    save user

    response { status: 201, body: user }
}

Si algún campo falla la validación, FLIN retorna un 400 Bad Request con información detallada del error:

json{
    "error": "Validation failed",
    "status": 400,
    "fields": {
        "name": "Must be at least 2 characters",
        "email": "Must be a valid email address",
        "age": "Must be at least 13"
    }
}

El código del handler nunca se ejecuta. Los datos inválidos nunca llegan a la base de datos. La respuesta de error le dice al cliente exactamente qué campos fallaron y por qué.

Decoradores disponibles

FLIN proporciona un conjunto completo de decoradores de validación:

Decoradores de tipo

Decoradores de restricción

flinvalidate {
    // Campos requeridos
    name: text @required                  // Debe estar presente y no vacío

    // Restricciones de cadena
    slug: text @minLength(3) @maxLength(50) @pattern("^[a-z0-9-]+$")
    email: text @email                    // Debe coincidir con formato de email
    url: text @url                        // Debe ser URL válida
    phone: text @phone                    // Debe ser número de teléfono válido

    // Restricciones numéricas
    age: int @min(0) @max(150)
    price: float @min(0.01) @max(999999.99)
    quantity: int @required @min(1) @max(10000)

    // Restricciones de enumeración
    status: text @one_of("active", "inactive", "pending")
    priority: int @one_of(1, 2, 3, 4, 5)

    // Restricciones de archivo
    avatar: file @max_size("5MB") @allow_types("image/png", "image/jpeg")
    documents: [file] @max_count(10) @max_size("25MB")

    // Mensaje de validación personalizado
    password: text @required @minLength(8) @message("Password must be at least 8 characters")
}

Validación vs. guards

La validación y los guards sirven propósitos diferentes y se complementan:

Guards protegen el acceso: ¿quién puede llamar a este endpoint? Los guards se ejecutan antes de que el cuerpo de la solicitud sea analizado. Un usuario no autenticado es rechazado antes de que se lea su cuerpo de solicitud.

Validadores protegen los datos: ¿qué forma deben tener los datos de entrada? Los validadores se ejecutan después de que los guards pasan y el cuerpo es analizado. Aseguran que los datos estén bien formados antes de que el handler los procese.

flinguard auth                    // Quién: solo usuarios autenticados
guard role("admin")           // Quién: solo administradores
guard rate_limit(10, 60)      // Con qué frecuencia: 10/minuto

route POST {
    validate {                // Qué: datos de usuario bien formados
        name: text @required
        email: text @required @email
    }

    // Si llegamos aquí:
    // 1. El usuario está autenticado (guard auth)
    // 2. El usuario es admin (guard role)
    // 3. La solicitud está dentro del límite de tasa (guard rate_limit)
    // 4. El cuerpo tiene nombre y email válidos (validate)
}

Cuatro capas de protección, cada una expresada declarativamente, cada una aplicada automáticamente.

La validación de FLIN no es una biblioteca que se instala. No es middleware que se configura. Es una característica del lenguaje que se compila a código eficiente de verificación de tipos, produce mensajes de error claros y no puede ser omitida. Cada endpoint API que usa un bloque validate está protegido contra entrada malformada, cada vez, automáticamente.

En el próximo artículo, vemos cómo verificamos que todas estas funciones de seguridad funcionan correctamente: 75 pruebas de seguridad cubriendo autenticación, autorización, limitación de tasa, validación de entrada y operaciones criptográficas.

Esta es la Parte 113 de la serie "Cómo construimos FLIN", que documenta cómo un CEO en Abidjan y un CTO de IA diseñaron y construyeron un lenguaje de programación desde cero.

Navegación de la serie: - [112] Autenticación OTP por WhatsApp para África - [113] Validadores de cuerpo de solicitud (estás aquí) - [114] 75 pruebas de seguridad: cómo verificamos todo - [115] Guards y middleware de seguridad personalizados