requestValidation

Maps Ktor's RequestValidation plugin failures to type, carrying every validation reason as one entry of an errors[] extension array. This is the multi-error pattern RFC 9457 itself recommends for field-level validation failures.

A reason produced by invalidField/invalidFields decodes into {"detail": ..., "pointer": ...}, RFC 9457's own example member names. Any other reason, a plain ValidationResult.Invalid("text") or the byte-array validate { } overload with no field to point at, decodes into {"detail": ...} alone, without pointer.

The entry shape is fixed. For a different one — other member names, extra members, a typed object — write the RequestValidationException mapping directly and read each reason with decodeValidationReason.

Parameters

Samples

install(RequestValidation) {
    // A real validator would parse `body` into a typed object; kept as raw text here so the
    // sample stays self-contained, with no JSON content-negotiation dependency of its own.
    validate<String> { body ->
        if (body.isBlank()) {
            invalidFields(
                "#/age" to "must be a positive integer",
                "#/profile/color" to "must be 'green', 'red' or 'blue'",
            )
        } else {
            ValidationResult.Valid
        }
    }
}

install(StatusPages) {
    problemDetails {
        requestValidation(ValidationError)
    }
}

routing {
    post("/customers") {
        call.respond(call.receive<String>())
    }
}