Skip to content
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

Use OpenRPC instead of REST API #2998

Open
phyro opened this issue Aug 23, 2019 · 0 comments
Open

Use OpenRPC instead of REST API #2998

phyro opened this issue Aug 23, 2019 · 0 comments

Comments

@phyro
Copy link
Member

phyro commented Aug 23, 2019

Is your feature request related to a problem? Please describe.
REST API is bound to HTTP. Until recently, JSONRPC did not have any specification similar to how OpenAPI is for REST, but now it does and it's called OpenRPC. Probably the main advantage of using this is that it is transport agnostic compared to REST - you can read about some other reasons here and here.

Describe the solution you'd like
As mentioned above, we now have OpenRPC and it comes with great tooling. One of them is their Playground which can be seen in action here with an Ethereum JSON RPC definition. There's also an Inspector tool that allows you to put an endpoint to a live server that knows how to respond to rpc.discover method and then you can interact with it.
Unfortunately, I don't have any endpoint to a live server, but I am going to append a gif that shows the nice developer/user experience in querying the data through inspector embedded in the playground tool.

Here's an example of playground tooling connected to the Ethereum Classic node that supports OpenRPC running on localhost and querying the methods the server supports
Gif of inspector and playground

Another cool thing is that it can generate the client code to communicate with the server specification. This means that given a my_json_spec.json that follows the OpenRPC spec, it can build the client-side code to interact with the server. Right now it supports Rust and Typescript. Link to client generator

Describe alternatives you've considered
I don't know any other alternatives.

Additional context
I don't know the details of how Grin is built so it could be that I'm wrong and that in this specific case REST is better. But given that communicating through OpenRPC is more 'lightweight', you could always build a wrapper for REST on top once you have an OpenRPC endpoint. If nothing else, think of it as a tool that could come handy in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant