Functional request mapping (webflux style):

    @Bean
    public RouterFunction<ServerResponse> route(VetsHandler vetsHandler) {

        return RouterFunctions
            .route(RequestPredicates.GET("/vets").and(RequestPredicates.accept(MediaType.TEXT_PLAIN)), vetsHandler::vets)
            .andRoute(RequestPredicates.GET("/vets.html"), vetsHandler::vetsHtml);
    }

Actuator has the following JSON data for the RM above:

          {
            "predicate": "((GET && /vets) && Accept: [text/plain])",
            "handler": "org.springframework.samples.petclinic.deviations.VetsRouter$$Lambda$868/443912630@369564bd",
            "details": {
              "handlerFunction": {
                "className": "org.springframework.samples.petclinic.deviations.VetsRouter$$Lambda$868/443912630"
              }
            }
          },
          {
            "predicate": "(GET && /vets.html)",
            "handler": "org.springframework.samples.petclinic.deviations.VetsRouter$$Lambda$869/1034259303@86ddd7c",
            "details": {
              "handlerFunction": {
                "className": "org.springframework.samples.petclinic.deviations.VetsRouter$$Lambda$869/1034259303"
              }
            }
          },

The MVC style RMs also have requestMappingConditions under details which has the data from the predicate string properly parsed. This data is missing from the JSON for functional (webflux style) RMs

STS team is in need of requestMappingConditions object for functional (webflux style) RMs (Similar to https://github.com/spring-projects/spring-boot/issues/12080#issuecomment-366295693). It'd be be great to have the same requestMappingConditions object for functional RMs, but if not something similar (with a list of path patterns) would do just as well.

Comment From: wilkinsona

When this was implemented all request predicates were a black box and there was no way to extract their details without resorting to reflection. This is changing in Framework 5.1.3 where the predicates can now be visited (SPR-17322). We might be able to do something on top of that.

Comment From: philwebb

It looks like SPR-17322 (now https://github.com/spring-projects/spring-framework/issues/21856) has been fixed so this might now be an option. We're still concerned that there are a lot of corner cases that we might not be able to cover. For example, a user can pretty much pick any predicate that they like. They can also compose them in quite complex ways that will be hard to represent in JSON.

Comment From: philwebb

Due to the number of corner cases and the limited demand for the feature, we've decided not to invest in this one. Thanks anyway for the suggestion.