OpenAPI Integration for generating RequestBody when referencing parts of a request body in micronaut

[akhil-ghatiki]

Hi everyone,

In our Micronaut application, we’re retrieving parts of the request body via reference rather than deserializing the entire object upfront. Here’s an example:

  @Operation(summary = "Create order", description = "Creates a new order for the given service.")
  @RequestBody(
        description = "The request body containing the order data.",
        required = true)
  @ApiResponses(...)
  @Post("/samplePath/{Id}/resources")
  HttpResponse<Order> createOrder(
      A authentication,
      @PathVariable @NotNull @ServiceTypes.Allowed({ServiceType.UNMANAGED}) RecourceId Id,
      @Body(REQUEST) @NotNull @Valid SampleRequestBody request,
      @Body(METADATA) @NotNull @Valid SampleMetaData metadata);

The incoming request body looks like this:

(metadata and request are at root level)

{
  "metadata": {
    "partnerId": "111100000",
    "channel": "RANDOM"
  },
  "request": {
    "payload": {
      "title": "My Order",
      "test": 123,
      "costsHumanReadable": "3.000"
    }
  }
}

We took this approach for these reasons - Structured Request Pattern, Validation Considerations, Metadata is consistently used across multiple endpoints

This approach works as intended in Micronaut, but the OpenAPI integration doesn’t seem to handle this use case correctly.

The RequestBody generated by the OpenAPI for this scenario is not as expected. It generated the request body as below:

(metadata and request are NOT at root level)

{
  "metadata": {
    "partnerId": "111100000",
    "channel": "RANDOM",
    "request": {
      "payload": {
        "title": "My Order",
        "test": 123,
        "costsHumanReadable": "3.000"
      }
    }
  }
}

Instead of manually working around this, we’re considering pointing this out to the contributors in case it’s a gap in the OpenAPI integration.

My questions are:

1. Is this a known limitation of Micronaut OpenAPI?
2. Are there existing workarounds for properly generating OpenAPI documentation in this scenario?
3. Would it make sense to raise this as an issue or feature request with the Micronaut contributors?

Any advice or insights would be appreciated!

Thanks in advance!

[altro3]

@akhil-ghatiki In Micronaut openapi all the features that users request or I come up with myself are gradually being implemented. What you wrote is not supported at the moment, but not because there are any restrictions, I just never used this micronaut feature and no one asked to add support for this feature.

You are the first one who did it :-).

Well, if you want this feature to be added - describe the case in detail in the issue: what code do you have, and what should be generated. And then I will add this feature.

For the future: it is better not to write in the discussions, but to create an issue. I forget to look through the discussions, so I do not answer for a long time

[altro3]

@akhil-ghatiki Anyway I already fixed it here: #1914 . Wait next release

[akhil-ghatiki]

Thank you @altro3
I wanted to understand if the scenario Is this a known limitation of Micronaut OpenAPI or if any work around is there before raising an issue. So, I started a discussion first.
Thanks for your time.

[altro3]

We manage the library restrictions ourselves :-) In any case, I forget to look through the discussions, so it's always better to create an issue