OpenAPITools / OpenAPITools/openapi-generator
[REQ] Allow fully skipping unsupported schemes from generated code
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Is your feature request related to a problem? Please describe.
I am receiving openapi.yaml files from external corporate APIs which I do not control.
These files contain both security schemes not supported by the generators I am using and other ones which are supported.
The calls to the corporate APIs are always done using the supported authentication methods, but the generated code contains mention of the (unused) unsupported security schemes and sometimes fails in unexpected ways because of them.
However, someone must always manually edit the openapi.yaml file before generating API client code, and keep doing such manual edit each time the API update (i.e. each time the openapi.yaml file needs to be replaced).
Describe the solution you'd like
For most generators, unsupported security schemes will be skipped in the generated code but included in the generated documentation. A generation parameter to always throw exception at generation time, or to always throw exceptions at runtime when these auth methods are used, or to always skip unsupported auth methods in the generated code would be nice because code and documentation would be consistent, and developers would be informed.
Describe alternatives you've considered
A script in my project to remove the unsupported security schemes, but maintenance is needed if switching to a new generator library or if upgrading the openapi generator version.
Additional context
It would be even nicer if the supported auth methods documented on https://openapi-generator.tech/docs/generators were the same ones as the ones actually supported in the code without the need to maintained separately both lists.
Moreover, consistency between generators of handling of unsupported schemes would also increase the trust that I can switch generator and be informed (latest) at generation time if it does not match my use case.
Finally, having a generic way to skip unsupported schemes or throw exceptions otherwise would help with testing, because there would no longer be the need t o maintain various subsets of test openapi.yaml files depending on the declared security schemes (e.g. with-fake-endpoints-models-for-testing-with-http-signature.yaml and with-fake-endpoints-models-for-testing.yaml)
Note: I can provide a PR handling the "skip unsupported schemes" feature for all generators as well as the "throw exception at generation time" feature, but not the "throw exception at runtime" feature because I am not fluent in all the coding languages of the various generators.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing how generators handle unsupported security schemes and compare the fixtures with-fake-endpoints-models-for-testing-with-http-signature.yaml and with-fake-endpoints-models-for-testing.yaml. Define whether generation should skip schemes or throw, then verify consistent behavior across generators and that generated code and documentation reflect the selected policy.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, openapi
- Domain
- api, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100