-
Notifications
You must be signed in to change notification settings - Fork 10
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
[PROPOSAL] Use API specification to generate clients #19
Comments
Note that the Rust client is generated from spec, see https://github.com/dblock/opensearch-rs/tree/main/api_generator/rest_specs |
The PHP client was generated also with the rest-spec. What I am unsure, it looks like we are building a second schema. So i am unsure if we should use the rest-sepcs. https://github.com/opensearch-project/opensearch-api-specification |
@shyim One reason to have opensearch-api-specification outside of OpenSearch core is that it also will/should contain schemas for various plugins, maybe as submodules (TBD). With everything I know I think I would invest in that repo, and delete everything else. |
I added "Add support for consuming multiple versions of the API spec in clients" above. I am not sure it's the best idea, but it's an idea nevertheless. I imagine the spec is either targeting a specific version of OpenSearch or is annotated with specific versions of OpenSearch (e.g. API since version X). With extensions it's going to be an n x m matrix, too. A possible approach is that the client carries multiple sets of generated code under a versioned namespace (e.g. |
What kind of business use case are you trying to solve? What are your requirements?
There are 9 language clients for OpenSearch in this organization. Each client is significantly different from another in their implementation (e.g. different pagination support or transport layer), but implement the exact same API (e.g. creating an index). That API matrix is huge, including multiple versions of OpenSearch and plugins that bring their own API.
What is the problem? What is preventing you from meeting the requirements?
The maintenance of clients is a large burden. Every time a new API is added or changed, every client needs to be updated, along with tests.
What are you proposing? What do you suggest we do to solve the problem or improve the existing situation?
Automate the update process by auto-generating non-interesting parts of the client.
As an example, https://github.com/slack-ruby/slack-ruby-client is built this way. The API specification is scraped from Slack in https://github.com/slack-ruby/slack-api-ref and the client uses templates for about 75% of its code.
Which clients use a generator today?
The text was updated successfully, but these errors were encountered: