We use cookies to enhance your browsing experience and analyze our traffic. By clicking "Accept All", you consent to our use of cookies.. View our Privacy Policy for more information.
Your browser (Internet Explorer) is out of date. Please download one of these up-to-date, free and excellent browsers:
For more security speed and comfort.
The download is safe from the vendor's official website.


Why we switched from a library to RESTful API

Crypto & Blockchain
Charlie Child
Mar 16, 2021

Why we switched from a library to RESTful API

2 min read

A library was sufficient in the earlier phases of HUMAN development, but in expanding HUMAN Protocol to support new apps and chains, we needed an interoperable, scalable, and seamless way to access the protocol.

What have we changed?

The previous model was a system whereby the components interacting with each other within HUMAN Protocol, namely the Exchange, required matching copies of the HMT escrow library. In this model, the library had to be updated within the Exchange system. This was acceptable as part of a growth-phase process; but, looking forward, it would be untenable for active and practical application of HUMAN Protocol. It would require constant updates in the Exchange system, resulting in down time, and lags due to mismatching libraries among the components.

The new system Swagger Specification RESTful API is a different configuration altogether. The Exchange now calls through the RESTful API to a server where an updated copy of the library is kept. All we have to do is update the server, and the components pointing at the server automatically update their libraries accordingly. In essence, we wrap the library code in an internal web server for the components to pull from and push to.

This is an essential part of making HUMAN Protocol multichain compatible. We will have one server per chain, which the programmes running on those chains can call to for the updated libraries. It makes it simple for new applications and chains to plug their interfaces in to the existing system.

There can be different classes of the server, too. While one server could be designed to interact with information specific to that chain, there could be another that changes the version of the library across all chains. This saves on downtime. All we have to do is point a component of a blockchain to a new server, as opposed to flipping out libraries, rebuilding and re-deploying programmes.

How we did it

We leveraged the data of our core services and libraries to design a generalist Swagger Specification. Using Swagger’s Codegen to provide the scaffolding, we then built out the REST Interface with new features, including:

  • Multi-chain support
  • 3rd party-apps
  • Factory based event hooks


At a fundamental level, this demonstrates our commitment to a multichain operability. HUMAN Protocol looks to provide a backbone for the data industry, which can only be achieved through a practical and open approach to chain infrastructure. To read more about our next steps in the pursuit of multichain interoperability, read our article about migrating to the sidechains.

For the latest updates on HUMAN Protocol, follow us on Twitter or join our community Telegram channel.

Legal Disclaimer

The HUMAN Protocol Foundation makes no representation, warranty, or undertaking, express or implied, as to the accuracy, reliability, completeness, or reasonableness of the information contained here. Any assumptions, opinions, and estimations expressed constitute the HUMAN Protocol Foundation’s judgment as of the time of publishing and are subject to change without notice. Any projection contained within the information presented here is based on a number of assumptions, and there can be no guarantee that any projected outcomes will be achieved.

Guest post