OpenAPITools / OpenAPITools/openapi-generator

[REQ] Allow fully skipping unsupported schemes from generated code

Open
#15,602 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Enhancement: Feature
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.