-
Notifications
You must be signed in to change notification settings - Fork 77
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
Develop OpenAPI Export for API Definition #1178
Comments
/bounty $10000 |
💎 $10,000 bounty • Golem CloudSteps to solve:
Thank you for contributing to golemcloud/golem! Add a bounty • Share on socials
|
/attempt #1178
|
/attempt #1178 Options |
1 similar comment
/attempt #1178 Options |
/attempt #1178 Options |
/attempt #1178 Options |
1 similar comment
/attempt #1178 Options |
💡 @zelosleone submitted a pull request that claims the bounty. You can visit your bounty board to reward. |
💡 @uurl submitted a pull request that claims the bounty. You can visit your bounty board to reward. |
In order to make it easy to standup REST APIs atop workers, Golem has a concept of "API Definition", which consists of a number of routes, with binding types, and implemented by the Worker Gateway (worker bridge + worker services).
Currently, two binding types are supported in the Worker Gateway:
Rib is a fully type-inferred language, and type information is available as metadata on existing REST APIs. This type information describes the type of input and output as a type in WASM's Component Model--see WIT for a sense of what these types can represent.
The Rib interpreter has a canonical mapping of values to Component Model types. It's deterministic and predictable and somewhat documented.
For all these reasons, it is possible to know exactly the input JSON and output JSON of every endpoint.
This ticket is to add a new REST API that can export an API Definition into a valid OpenAPI Specification, preserving the request and response types. Separately, the OpenAPI Specification needs to correctly represent security and CORs, which are features of the Worker Gateway. Any client library generated from the OpenAPI Specification needs to be able to work correctly with the real REST API.
Moreover, the ticket also calls for use of the OpenAPI Spec to generate a Swagger UI; and for a new binding type in the Worker Gateway, which can trigger the Worker Gateway to serve the Swagger UI at the specified endpoint.
Together, all these features will provide very good support for consuming REST APIs built with the Worker Gateway.
To close out this ticket, the following tasks must be completed:
The text was updated successfully, but these errors were encountered: