X-Road REST Survey Results

The Nordic Institute for Interoperability Solutions (NIIS) did a survey regarding REST support for the X-Road. The results don’t leave any room for doubts – 93 % of the participants want the X-Road to support REST. Only 7 % of the participants are not interested in REST at all. The X-Road community has spoken.

About the survey

The survey was open from 19th March till 13th April and it was promoted through different social media channels of the NIIS. In addition, all the Estonian X-tee members and Finnish Suomi.fi Data Exchange Layer (Suomi.fi-palveluväylä) members were invited to answer the questions. The survey collected 75 responses of which 32 are from the Suomi.fi Data Exchange Layer members, 24 are from the X-tee members and 19 are from other parties interested in the X-Road.

Image 1. Participants background.

Summary

One thing is sure – the answers show without a doubt that REST support is wanted by the X-Road community. According to the majority of the participants it’s enough to support consuming and producing services using their native implementation. It is also enough to have the service descriptions available based on the native implementation of the service – WSDL or OpenAPI specification. Automatic SOAP-REST conversion is not expected which means that if a service provider wants to provide both SOAP and REST versions of the same service the provider must implement both versions.

In many questions the differences between answers are not big and it must be also considered that part of the participants did not express their opinion. If all the “I don’t know / I’m not sure” answers were added to the answer that came second, the first and the second answer would be even. This does not change the fact that REST is wanted, but it has an effect on the level of the support that is expected. On the other, if all the “I don’t know / I’m not sure” answers were added to the answer that came first, the difference would be even clearer than it is now.

It is also worth noting that more than half (61 %) of the participants is interested in how the X-Road handles SOAP and REST messages internally. In addition, the information also effects on their decisions when planning how to integrate their services. Based on this it is not indifferent how the REST support is implemented.

Results

The questions and their answers are presented below.

Image 2. Would you like to consume or produce REST services through X-Road?

Image 3. What type of REST services (CRUD) you would like to consume or produce?

Image 4. Should all the services be available using both SOAP and REST regardless of their native implementation?

Image 5. Should all the service descriptions be available in WSDL (SOAP) and OpenAPI specification (REST) regardless of the native implementation?

Image 6. Are you interested in the details how X-Road handles SOAP and REST messages internally?

Image 7. Should REST version of a SOAP service and SOAP version of a REST service be automatically provided by X-Road?

What next?

The survey provided more insight regarding expectations for the X-Road REST support and the results serve as a great input for the next phase of planning.

The NIIS will organize an X-Road REST workshop in Tallinn in May. The workshop is targeted for the participants of the survey who expressed their interest towards the workshop and left their contact information when they completed the survey. More information regarding the REST support and the outcome of the workshop will be available in May. The road towards REST will continue.

There is no blockchain technology in X-Road

Recently there have been multiple writings about the X-Road which have stated that X-Road is a blockchain based technology or it utilizes blockchain internally. Are these claims true, is X-Road based on blockchain? Let’s take a look at the facts.

Blockchain

Blockchain is one of this year’s buzzwords and one of the hottest technologies out there. Blockchain became known as the technology behind bitcoin – the first cryptocurrency launched in 2009. Since then its use has expanded to cover many different business areas and use cases in addition to cryptocurrencies.

Blockchain is a distributed, decentralized and public database that stores transactions in a chain that protects them against alterations and ensures data integrity. Blockchain is a peer-to-peer network where all the nodes are equal and every node has a full copy of the blockchain. The data stored in a blockchain cannot be altered afterwards without altering all the subsequent blocks and replicating the changes to all the nodes of the network. This makes tampering the data stored in a blockchain extremely difficult.

Transaction data is stored in blocks in the form of a Merkle tree. Consecutive blocks are linked to each other so that together they form a chain. Each block contains the cryptographic hash of the preceding block in the chain which makes it possible to verify the order and the integrity of the blocks from the previous block till the very first block of the chain, the genesis block. This makes it possible to audit and verify all the transactions in the chain.

Blockchain does not have a central authority so the nodes need to come to a consensus before a new block can be added to the chain. This is achieved by using a consensus protocol or consensus mechanism. The most common consensus mechanisms are called Proof of Work (PoW) and Proof of Stake (PoS).

X-Road

X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. X-Road is a centrally managed distributed integration layer between Information Systems that provides a standardized and secure way to produce and consume services. X-Road ensures confidentiality, integrity and interoperability between data exchange parties.

The identity of the service producers (i.e. base registries) and consumers (i.e. web portals) is maintained centrally by the X-Road operator and all the data is exchanged directly between the data consumer and provider.  All the evidence regarding the data exchange is stored locally by the data exchange parties, and no third parties have access to the data. Time-stamping and digital signature together guarantee non-repudiation of the data sent via X-Road.

X-Road supports batch signatures and batch time-stamping. Batch signatures are created for messages that contain attachments. Batch time-stamping means that time-stamps are created asynchronously in batches for all the messages that have been processed since the last batch time-stamping. Batch time-stamping is used for reducing the load of time-stamping service. Both these features are based on Merkle hash trees and the messages processed during a single batch are linked to each other through a hash chain. Using the hash chain it is then possible to verify that a selected message is a part of a certain batch signature. However, there is no link between different batches and messages in them so there’s no chain that would link all the batch processed messages together.

The security server stores all the processed messages with their signatures and time-stamps in the message log database. The log records are archived to disk regularly and removed from the database after that. In the message log archive file each message has a cryptographic hash that depends on the previous message that was archived and the chain continues over different archive files. In this way the message log archive files create a chain that contains all the messages processed on a single Security Server. This means that the messages stored in the message log archive files cannot be modified without breaking the chain.

Is X-Road based on blockchain?

Blockchain is a decentralized and distributed database which is updated through a consensus protocol. All the nodes of the network are equal and every node has a full copy of the database. The blocks stored in the database are linked to each other using cryptographic hash functions.

The X-Road Security Server message log archive files contain all the messages processed by a single Security Server. Messages included in the files are linked to each other using cryptographic hash functions. The files are stored locally and the server hosting the files is responsible for creating them. Each Security Server has its own unique chain of processed messages. Other members of the X-Road ecosystem do not have access to the files.

The common factor between blockchain and X-Road is that they both use cryptographic hash functions for linking data items to each other. Besides that there are very few common factors between the two as they serve very different purposes and use cases. Cryptographic hash functions existed well before blockchain so even if the both blockchain and X-Road use them does not mean that X-Road is based on blockchain. Both bicycle and car have wheels, but we don’t say that car is based on bicycle just because the bicycle was the first one to use wheels. The same goes with blockchain and X-Road.

Based on the arguments presented above the outcome is that X-Road is not based on blockchain and does not use it internally.

X-Road and REST

X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. More information about the X-Road is available at:

https://www.niis.org/data-exchange-layer-x-road/

The X-Road and REST have been a topic in public discussion for quite some time already. Today the X-Road does not have a built-in support for REST, but that does not mean anything has happened regarding the topic in the recent years. And there’s even more to come later this year...

At the moment REST services can be produced and consumed over the X-Road using the REST Adapter Service component. The service supports a limited set of use cases so it’s not an answer to all X-Road REST integration questions. However, it is an off-the-shelf component that provides an X-Road compatible REST-SOAP converter, and it can be implemented over configuration – no coding is needed. Compared to a custom-built solution it can save a great deal of effort.

https://github.com/vrk-kpa/REST-adapter-service

How does it work today?

X-Road message exchange protocol is based on SOAP and all the information systems and services that exchange data over the X-Road must implement the protocol. For older SOAP based information systems and systems that have been using the X-Road for years this is not a problem as the systems already have a working implementation of the X-Road message exchange protocol.

For new information systems and new X-Road user organizations things might not be that simple because nowadays the most APIs are RESTful in nature and use JSON instead of XML. This means that an additional REST-SOAP adapter service must be implemented between the information system and the X-Road Security Server. The REST Adapter Service component is one alternative or organizations may implement their own custom-built solutions. Either way, it is technically doable, but not a very compelling alternative for organizations that have already moved away from SOAP and have implemented their APIs using REST and JSON. In addition, all the extra components in the stack bring more overhead, delay, maintenance work, costs etc.

What do the numbers say?

ProgrammableWeb is one of the largest information and news sources about the Web as a programmable platform and it maintains a directory of over 15,500 web APIs. According to its statistics REST is the most common architectural style with the share of 81 % of all the APIs listed in the ProgrammableWeb’s API directory. At the same time RPC’s share, that’s including also SOAP, is only a bit under 9.5 %. These numbers give a good overall picture regarding the popularity of different architectural styles today. The whole article is available at:

http://web.archive.org/web/20220712162418/https://www.programmableweb.com/news/which-api-types-and-architectural-styles-are-most-used/research/2017/11/26

What next?

Based on available statistics and the public discussion in the recent years, it seems obvious that the X-Road needs a better support for REST than the REST Adapter Service is able to provide now. The lack of the REST support is slowing down the adaption of X-Road and generating unwanted additional work for many X-Road user organizations. However, adding support for REST does not mean dropping support for SOAP – not any time soon, at least. Instead, the two architectural styles can co-exist side by side which means that all the current SOAP services must be supported also after the REST support has been implemented. Then it will be another discussion for how long both SOAP and REST must be supported side by side.

Tell us what you think!

What do you think about the X-Road and REST? The Nordic Institute for Interoperability Solutions (NIIS) is doing a survey regarding REST support for the X-Road. The survey is open until the 13th of April, tell us what you think:

https://buff.ly/2G7wtl9