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
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
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.
The text was updated successfully, but these errors were encountered:
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 supportsAnother 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 generatorDescribe 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.
The text was updated successfully, but these errors were encountered: