Support @PathVariable in Functional Closures Returned by WebFlux Endpoints

[zapphyre]

Allow @PathVariable, @RequestParam, and similar annotations on parameters of functional closures (e.g., Consumer, Function) returned by Spring WebFlux endpoints.

Motivation:

Spring WebFlux’s functional endpoints lack support for annotating closure parameters with @PathVariable. This forces developers to pass parameters explicitly, making code less concise. For example:

@PutMapping("decrement/{word}")
public Consumer<@PathVariable("word") String> adjustVocabDown(@PathVariable("langId") Long langId) {
    return word -> languageService.propVocabularyFreq(langId, changeFrequency.apply(decrement)).accept(word);
}

Supporting annotations in closures would simplify endpoint definitions and align with Spring MVC’s annotation model.

Proposed Solution:

Enable Spring (WebFlux, Web) to process @PathVariable, @RequestParam, and @RequestBody on closure type parameters. Bind request data (e.g., path variables) to these parameters automatically, similar to annotated controllers.

[sdeleuze]

I am a bit confused by what is asked, are you proposing such feature for the annotated programming model or the functional one?

[zapphyre]

exactly what you can see in the code snippet: be able to return Function/Consumer from an endpoint and annotate consuming parameters with @PathVariable/@RequestParam so that framework can extract given param representation and use it just like regular instance parameters now.

[sdeleuze]

I don't think you are gaining much from a code conciseness perspective and from a programming model and lifecycle perspective, looks confusing to me. Would also require to add ElementType.TYPE_USE to Spring MVC annotation @Target which would means it could be used with types where that won't be supported. As a consequence, I decline this enhancement proposal and advise to continue using parameter level annotations.

[sbrannen]

In addition to what @sdeleuze said, this request is effectively a duplicate of the following.

• Find TYPE_USE annotations on anonymous classes via the MergedAnnotations API #31360
• Make AnnotationsUtils.findAnnotation() recognize annotations on anonymous classes again #28896