-
-
Notifications
You must be signed in to change notification settings - Fork 55
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
Allow multiple input/output signatures for the same method name #367
Comments
Welcome to OpenRPC! Thank you for taking the time to create an issue. Please review the guidelines |
As a fellow Solana-ite, I support @steveluscher request. That being said, the propose methods would probably provide a spec that is too ambiguous when it comes to API client generation, especially for lower level languages like C/C++. A generator must know how to generically create the overloads, so the spec must somehow indicate how response schemas change and not leave that work up to a specific client implementation. The way that OpenAPI 3.0 approaches it is via It looks like this
I would imagine that something very similar is doable for OpenRPC. |
To add more context, Some discussion in OpenAPI about this exact issue: |
So in theory, this kind of OpenRPC schema would be helpful for codegen:
Of course, this passes 'json-schema' validation because it would simply ignore unknown stuff. But it would be nice to have it as an official OpenRPC extension of json-schema rather than a free-for-all implicit abuse of validator permissiveness. |
Problem
In the docs for
Method
it is written:Consider a JSON-RPC API method of ours called
getBlock
. If you passtransactionDetails: 'full'
in the input then the output takes this form:If, however, you pass
transactionDetails: 'accounts'
then the output takes this form:Without the ability to specify two different input/output signatures for the same method name, I don't think I can use OpenRPC to express that API.
Proposed solution
Allow multiple definitions for the same method name, and let the consumers of the specification document figure out how to either:
The text was updated successfully, but these errors were encountered: