API means Application Programming Interface and specifies how software should interact. It explains how a consumer can consume the service the API exposes: what URIs are available, what HTTP methods may be used with each URI, what query string parameters it accepts, what data may be sent in the request body, and what the consumer can expect as a response.
There are multiple approaches to API, but there are two of them that compete in the development environments often than others: REST API and RPC API. REST is focused on work with sources. Server owns URL except for a single entry point URL, and the clients have the flexibility to access individual services by following links. In its turn the RPC fits things like message passing, very dynamic and multidimensional queries, requesting view models, triggering events, remote algorithm execution, sending mutations. Server and client have the share of URL on which operations are performed.
Initially, we chose the REST API so that users and developers could test our nodes and custom blockchain. As you know, this is a somewhat popular method that provides interoperability between computer systems on the Internet.
REMME REST-API consisted of 5 sections:
- Default section — responsible for generic endpoints available to interact with a chain.
- Node Management section — responsible for managing public keys within the node.
- Token Operations section — allows one to retrieve information regarding account and transfer tokens.
- Public Key Infrastructure section — Unlike node management tools, it allows storing public key information on-chain.
- X.509 section — Allows storing certificate information.
After having several hackathons and launched REMME testnet, we had gotten feedback from our community that complexity of REST API isn’t relevant for current masternodes functionality requirements and needs complex support from our side.
We stated that for simplicity purposes RPC approach is better since it is all about executing the remote code as fast possible without focusing on longevity and reduced client-coupling that are available in REST. A RESTful system is tied to the uniform interface of the supporting protocol HTTP and cannot tunnel through multiple protocols, unlike RPC. REST requires you to make many choices to provide a reliable, quality experience for consumers, that isn’t useful and comfortable in our case.
We can also highlight other benefits of RPC:
- Tight coupling. The components of the system are designed to work together, and changing one will likely impact all of the others. It is unlikely that the components will have to be adapted to communicate with other systems in the future.
- Reliable communication. The components will communicate with each other either entirely on the same host or on a network that is unlikely to experience latency issues, packet loss, etc.
- Uniform language. All (or mostly all) components will be written in a single language. It is unlikely that additional components written in a different language will be added in the future.
So we decided to change our API to JSON-RPC API for providing REMME tech community more simple tool that thoroughly enough for using current REMChain features and can be faster understood for newcomers. Learning the procedures of a PRC API is very similar to learning a new programming library. So its implementation for REMME protocol tends to be efficient — the data that is passed between the client and the server is usually encoded in binary formats, and the RPC style encourages relatively small messages (although some care has to be taken to avoid overly chatty interactions).
You’ll find JSON-RPC API documentation here.
.png)
