You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This spec represents a minimum sufficient interface that clients should support.
However this spec does not limit the client from supporting further methods or documenting them via this method.
Instead of multigeth returning a static minimum-viable string at this endpoint, it would be really great to be able to have multigeth actually return a complete representation of the methods that it is making available, which are a lot.
"Handrolling" a specification object to this purpose costs technical debt in the short and long terms, is prone to error, and generally an inelegant way of solving the challenge.
Better, to devise a system that can be applied at the RPC server level, which can programmatically generate an OpenRPC schema fitting the actual API available. This would work, then, hand-in-hand with github.com/gregdhill/go-openrpc (that codebase can consume schemas but not generate them).
The text was updated successfully, but these errors were encountered:
Currently the
rpc.discover
API method returns a static string, fitting the spec documented here: https://github.com/etclabscore/ethereum-json-rpc-specification/blob/master/openrpc.json.This spec represents a minimum sufficient interface that clients should support.
However this spec does not limit the client from supporting further methods or documenting them via this method.
Instead of multigeth returning a static minimum-viable string at this endpoint, it would be really great to be able to have multigeth actually return a complete representation of the methods that it is making available, which are a lot.
"Handrolling" a specification object to this purpose costs technical debt in the short and long terms, is prone to error, and generally an inelegant way of solving the challenge.
Better, to devise a system that can be applied at the RPC server level, which can programmatically generate an OpenRPC schema fitting the actual API available. This would work, then, hand-in-hand with github.com/gregdhill/go-openrpc (that codebase can consume schemas but not generate them).
The text was updated successfully, but these errors were encountered: