Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenApi Should support OpenAPI 3.1 AND thus OneOf for Enums AND Generics. #58239

Open
1 task done
JohnGalt1717 opened this issue Oct 4, 2024 · 2 comments
Open
1 task done
Labels
area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc feature-openapi ✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. Status: Resolved

Comments

@JohnGalt1717
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Right now, enums don't populate at all unless you globally override Json serialization. #58230

But that's just OpenAPI 2.0 support that doesn't solve the real problem of enums in OpenAPI in that they can't represent key/value pairs.

Further, there is no support at all for generics in the current implementation so Result just gets generated as endless duplicate types instead of using the OpenAPI 3.1 spec that allows these to just be Result with optional generic definitions as properties inside the object.

Describe the solution you'd like

By supporting Open API 3.1 across the entire set of libraries for OpenAPI this can be fixed so that C# can generate a full expression of what would create a great cllent: Enums with key/values and Generics that don't repeat themselves. as 2 instances. I'm sure there are other use cases for the Open API 3.1 spec.

This should also be extended with support into Kiota for all of this as well so that it is coordinated across the entire generation cycle from server to client(s).

Additional context

As noted in the referenced ticket it's possible to hack this functionality in, but it should be at the root and just done automatically as it doesn't break existing client generators by adding this support, while it creates much richer and cleaner clients when it is implemented.

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-web-frameworks *DEPRECATED* This label is deprecated in favor of the area-mvc and area-minimal labels label Oct 4, 2024
@martincostello martincostello added feature-openapi area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc and removed area-web-frameworks *DEPRECATED* This label is deprecated in favor of the area-mvc and area-minimal labels labels Oct 4, 2024
@captainsafia
Copy link
Member

@JohnGalt1717 Supporting OpenAPI v3.1 is a long-term goal of this effort. However, we're limited by the fact that the underlying OpenAPI library we use (https://github.com/microsoft/openapi.net) doesn't support OpenAPI v3.1 yet.

They are in the process of adding that support in a new major version of the package that we intend on upgrading to consume these new APIs when those updates are released.

@captainsafia captainsafia added the ✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. label Oct 4, 2024
@JohnGalt1717
Copy link
Author

Ok, that's fair, but I'd like to see captured the todo specifically of proper support of Enums and generics. The former of which is currently outright broken while it works using OpenAPI 2 in Swashbuckle and Nswag right now which depend on the same library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc feature-openapi ✔️ Resolution: Answered Resolved because the question asked by the original author has been answered. Status: Resolved
Projects
None yet
Development

No branches or pull requests

3 participants