The OpenRPC Specification defines a standard, programming language-agnostic interface description for
JSON-RPC 2.0 APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenRPC, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, the OpenRPC Specification removes guesswork in calling a service.
Although this was created by ECLC, the ramifications and it’s impact should be felt across all blockchain dApp development.
This Twitter post sums it up best:
Unstoppable code. Un-censorable messages. Incompatible Protocols
Sure, we all love the idea of building things without having someone in charge of everything. The benefit of these systems is a new version of freedom we are all still wrapping our heads around, but the drawbacks have been felt in building. The tools and protocols developers are using are not standardized, and this leads to inevitable complications when trying to organize globe-spanning ecosystems that are supposed to eventually work without any human intervention.
JSON-RPC is the defacto data exchange protocol that blockchain clients and servers use to communicate. Although most modern frameworks depend on RESTful API’s, “RPC is more suitable due to its it being simple, fast, and communication channel agnostic.” says ECLC developer Shane Jonas
Google’s API Design Guide defines Networked APIs as:
Application Programming Interfaces that operate across a network of computers. They communicate using network protocols including HTTP, and are frequently produced by different organizations than the ones that consume them.
As we continue building, different organizations will get out of sync. This is an issue for interacting with systems outside of your own, and inevitably this will become an obstacle towards our collective goal to build decentralized systems that can cooperate with one another. By creating canonical definitions for RPC (which is used by virtually every blockchain), ECLC has created something that the entire ecosystem needed.
OpenAPI set the standard for API description adoption
This isn’t a new, novel idea. OpenAPI, the specification most used for REST APIs, has been widely applauded and now supported by the Linux Foundation (including Google), a testament to the importance of having these kind of globally agreed upon protocols.
The OpenAPI Specification wasn’t the first API description format, but so far it has been the most widely used. Before we had API description formats, people hand-wrote the code for their APIs. Then they hand-wrote descriptions of those APIs and handed those to people who wanted to use the APIs, who then hand-wrote code to call the APIs. All of that hand-writing led to a lot of variation and error. As a formal description format, OpenAPI is giving us a great way to communicate about APIs and to have fewer errors and more successes in our API-based systems — Tim Burks
The OpenRPC Specification is built on the same philosophies and methods as OpenAPI
- Automatic Updates
- High Quality
- Known Services
The Roadmap laid out by the ECLC team shows that this was just the first step in building a better JSON-RPC framework.
JSON RPC Schema ~Q1 — Q2 2019: Create ECLIP for automated JSON Schema generation from Classic-Geth and Multi-Geth. This will reduce operational costs related to libraries. This improvement would make the DApp development environment more efficient by removing the need for RPC APIs such as Web3 or Emerald JS.