Split operation with multiple return types

[borsch]

This is a fix for issues like

• [BUG] [Spring] Default interfaces do not contain response mediatypes except application/json #11731
• [REQ] [sprind-cloud] Provide multiple response bodies  #8701
• [BUG] [sprind-cloud] Multiple response bodies generates invalid code #8700

There might be even more like those. The general idea of this PR is to split operation with different return types(content types) into multiple. While request for this feature was only for Spring, I did a global change since it was simpler to do in core, rather then in specific generator.

New flag is introduced to control this behavior and it's disabled by default

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Core team since this affects default generator: @wing328 @jimschubert @cbornet @jmini @etherealjoy @spacether

And java related committee since tests currently written for java/spring only:
@bbdouglas (2017/07) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01) @karismann (2019/03) @Zomzog (2019/04) @lwlee2608 (2019/10)
@cachescrubber (2022/02) @welshm (2022/02) @MelleD (2022/02) @atextor (2022/02) @manedev79 (2022/02) @javisst (2022/02) @borsch (2022/02) @banlevente (2022/02)

[borsch]

FYI @networkinss @MelleD @tamershahin

[wing328]

Thanks for the PR. Please resolve the merge conflicts when you've time.

[borsch]

@wing328 done. please check

[wing328]

Do we need to make similar change in the CLI as well?

[borsch]

@wing328 you talk about this repo https://github.com/OpenAPITools/openapi-generator-cli ?

[wing328]

The openapi generator cli module in this project

[borsch]

will check

[borsch]

@wing328 done. please check

[spacether]

We already store multiple response media types in the Java layer in CodegenResponse.content
Have you considered using this information to write one function per content type at the template level?

[borsch]

@spacether my implementation is cross language/library

[borsch]

@wing328 could you please check

[cv]

Hi folks! Currently bumping into this issue in the TypeScript node generator, so having a global way to deal with it seems like a great way to go.

[Christina0114]

Hi, I try it on my own open api file, i find the names of generated functions are not very good. Do you ever consider multiple request content types?

[borsch]

@Christina0114 what do you mean by "not very good names"?

Do you ever consider multiple request content types?

Not as for now

[borsch]

Hi @wing328
Could you please review this PR?

[spacether]

@spacether my implementation is cross language/library

Using the Java layer data that already existing on master branch is also a is cross language/library solution

Our code already store multiple response media types in the Java layer in CodegenResponse.content
Have you considered using this information to write one function per content type at the template level?

In 3.0.X specs, a response doe not have a datatype. It's content object has a datatype per the spec:
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#response-object
Continuing to store and use data type at the CodegenResponse level will make moving to openapi v3.1.0 spec support more difficult because the new specs do not store responses data types there.

Please consider using CodegenResponse.content because

• it has the data that you need
• it will make moving to openapi 3.1.0 easier in the future
• you can use similar logic for multiple request content types also

You can iterate over it and generate multiple interfaces/fns/classes with separate return types.
That is exactly what this template does here which generates this code.
If you want to move forward with this PR that is fine, it will just make it a little more difficult for generators who use these separate codegenResponses to migrate to openapi 3.1.0 support.