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.
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:
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: