WebFlux functional DSL does not recognise query parameters

[Sam-Kruglov]

This route from the WebFlux functional demo https://github.com/springdoc/springdoc-openapi-demos/blob/ff9b81f88ce1c66ffb5bf70d9bbbd69f5d77aed6/springdoc-openapi-spring-boot-2-webflux-functional/src/main/java/org/springdoc/demo/app4/user/RoutingConfiguration.java#L21
has 2 issues:

1. user parameter is documented as type "string" but it should be a User object. But this can be fixed by accepting User instead of Mono<User>, so it's not the fault of springdoc.
2. If I change the id parameter from PATH to QUERY then it is documented as a single body schema that contains id field and user field. But I want id to be a query parameter and user to be in the request body. @RequestBody on user is ignored.

also, maven project doesn't seem to include -parameters compiler flag, so the real parameter names aren't seen by reflection

[Sam-Kruglov]

Also, unrelated, why do we need to call route().GET(...).build().and(route().GET(...).build()) instead of just route().GET(...).GET(...).build()? Both seem to do the same

[bnasslahsen]

@Sam-Kruglov,

You shouldn't need any additional settings. It should work out of the box.
The issue related to the parameters naming when using proxy libraries like CGLIB, that's why you are getting arg0, arg1 in the samples demos, but not reproducible in the tests.

This is now fixed in master, so you can test it with the latest snapshot. And it will be available for the next release.

For your second question, both syntaxes are possible.

[Sam-Kruglov]

@bnasslahsen thanks for the answers!

But what about issues 1 and 2 that I mentioned? It's still a problem for me, or maybe I don't understand something

[bnasslahsen]

@Sam-Kruglov,

You should just test, with the latest master version. Not sure the SNAPHSOT is yet available in maven central. But you can build it in local...

Anyway, you could use the following test result as reference of the generated OpenAPI documentation:

• https://raw.githubusercontent.com/springdoc/springdoc-openapi/master/springdoc-openapi-webflux-core/src/test/resources/results/app82.json

What you want to 2) is not possible in OpenAPI 3. You can read the spec for more details.

[Sam-Kruglov]

sorry for bugging you but point 2) is not clear. I wish to describe this:

PUT /api/user/put?id=1
{
  "firstName": "John",
  "lastName": "Smith"
}

So, the result should be something like this:

paths:
  /api/user/put:
    put:
      parameters:
        - in: query
          name: id
          schema:
            type: integer
          required: true
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/User'

So, instead of this:

public Mono<User> putUser(@Parameter(in = ParameterIn.PATH) Long id, Mono<User> user);

I do this and expect it to work:

public Mono<User> putUser(@Parameter(in = ParameterIn.QUERY) Long id, Mono<User> user);

But it results in what you see on the screenshot.

The link you gave doesn't say it's not possible, or, perhaps I'm missing something?
Here's a quote from that link:

OpenAPI 3.0 uses the requestBody keyword to distinguish the payload from parameters (such as query string).

[bnasslahsen]

@Sam-Kruglov,

I see what you want now.

If you just respect the contribution guide, you will make your requests easier for you and for us.

This is what is already written: If you are reporting a bug, please help to speed up problem diagnosis by providing as much information as possible:

• You need to describe your context (the title of an issue is not enough)
• What version of spring-boot you are using?
• What modules and versions of springdoc-openapi are you using?
• What are the actual and the expected result using OpenAPI Description (yml or json)?
• Provide a Minimal, Reproducible Example - with HelloController that reproduces the problem

Please make sure you respect this guidelines if you open any new issue.

[Sam-Kruglov]

Similar issue is still present for me. I will open another issue if I have time. But basically, if I specify beanClass and methodName, and there I have parameters MyDto, String, String and the operation is not GET, then the resulting spec will have a request body with all these parameters as a single object similar to what we have here on the screenshot.

I say that any request body that does not set $ref to /components/schema is wrong.

If I specify @RequestBody MyDto, @Parameter String, @Parameter String then nothing changes. I have to explicitly say @RequestBody MyDto, @Parameter(in=QUERY) String, @Parameter(in=QUERY) String for it to change as I want.

I think it is a reasonable default to assume the dto is in the body and any literals is a query parameter unless specified otherwise. Always building a composite request body seems a very strange approach. I saw there a condition to always create a request body if the HTTP method is anything except GET (see the only usage of org.springdoc.core.RequestBodyService#calculateRequestBodyInfo). I might not have any body in POST request. Hopefully that helps.

upd: current workaround:

/**
 * If a method has parameters (DTO, String, String) it will create a request body with 3 fields containing all these.
 * We could annotate every single place with [io.swagger.v3.oas.annotations.Parameter] or we could write a customizer
 * like this one to pick out all the non-complex objects out of request body
 */
@Bean
fun moveSimplePropsFromBodyToQuery() = OperationCustomizer { operation, _ ->
  val content = operation.requestBody?.content?.get(APPLICATION_JSON_VALUE)
  if (content?.schema != null && content.schema.`$ref` == null) {
    val simpleProperties = content.schema.properties.entries.filter { (_, value) -> value.`$ref` == null }
    simpleProperties.forEach { content.schema.properties.remove(it.key) }
    Assert.state(
        content.schema.properties.size <= 1
    ) {
      "Found more than one complex property in method parameters of ${operation.operationId}. " +
          "Consider annotating them with @RequestBody or @ParameterObject, or declaring as a composite single object."
    }
    if (content.schema.properties.size == 1) {
      content.schema = content.schema.properties.values.first()
      // for some reason it's marked as not required by default
      operation.requestBody.required(true)
    } else {
      // empty -- found merged schema with only simple properties
      operation.requestBody = null
    }
    simpleProperties.forEach { (name, schema) ->
      //schema.nullable is always null
      operation.addParametersItem(QueryParameter().name(name).schema(schema).required(!(schema.nullable ?: false)))
    }
  }
  operation
}