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

Introduce more usable public API #1762

Closed
MikeEdgar opened this issue Mar 6, 2024 · 0 comments · Fixed by #1774
Closed

Introduce more usable public API #1762

MikeEdgar opened this issue Mar 6, 2024 · 0 comments · Fixed by #1774
Assignees
Labels
enhancement New feature or request

Comments

@MikeEdgar
Copy link
Member

MikeEdgar commented Mar 6, 2024

Currently, platforms integrating with smallrye-open-api make use of some combination of at least the following classes:

  • io.smallrye.openapi.api.OpenApiConfig
  • io.smallrye.openapi.api.OpenApiDocument
  • io.smallrye.openapi.runtime.OpenApiProcessor
  • io.smallrye.openapi.runtime.OpenApiStaticFile
  • io.smallrye.openapi.runtime.io.OpenApiParser
  • io.smallrye.openapi.runtime.io.OpenApiSerializer
  • io.smallrye.openapi.runtime.scanner.AnnotationScannerExtension
  • io.smallrye.openapi.runtime.scanner.spi.AnnotationScanner

Many of the classes provide overloaded static methods that makes it hard to make modifications without studying each client.

We should have a single unified public "builder" style API that users access to generate OpenAPI models and de-/serialize them to/from YAML or JSON. It is a goal to limit exposing internal smallrye-open-api types in this new API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant