feat(server): add swagger ui support for api documentation #790
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
hey, sorry for the delay, giving me two options froze me lol. will discuss with the team this week, we also want to expose openapi docs on the website as well. |
|
No problem! Yeah sorry if it was overwhelming haha |
1 similar comment
|
No problem! Yeah sorry if it was overwhelming haha |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds Swagger UI support to the opencode server, providing an interactive API documentation interface.
Changes
@hono/swagger-uidependency/uiendpoint/docImplementation
I followed the standard Hono Swagger UI documentation approach as shown in their official examples. This provides a clean, minimal integration that leverages our existing OpenAPI specification.
Proposal: support both Swagger UI and Scalar UI
See also #791 which implements Scalar UI on
/scalaras an alternative documentation interface. Both UIs can coexist without conflict.I believe we could support both documentation UIs simultaneously:
/ui- The industry standard that most developers are familiar with/scalar- A modern alternative with enhanced featuresThis would give users choice based on their preferences and use cases.
What do you think? Should we support both, or would you prefer to choose one? I'm open to discussion!