The NIIS organized an X-Road REST support ideation and planning workshop on 8th May in Tallinn. The workshop was targeted for the participants of the previously implemented REST survey who expressed their interest towards the workshop and further involvement in the planning process. The aim of the workshop was to get more insight on implementing REST support from real X-Road users.
Image 1. Beginning of the REST support workshop.
Workshop agenda
The workshop had around 20 participants from Estonia and Finland who were representing different public and private sector organizations. The program of the workshop was built around three themes:
X-Road REST support survey results
REST support implementation alternatives
Next generation X-Road
The format of the workshop allowed the participants to have time for discussions and group working. Each section started with an introductory presentation on the topic which was followed by a group assignment and a joint discussion.
X-Road REST support survey results
The first part concentrated on the X-Road REST support survey results. Overall, the participants’ opinions were aligned with the survey results – basic support which means consuming and producing SOAP and REST services using their native implementations is enough. Automatic conversion between different service types is not required.
The most intensive discussion was about defining REST in the context of the X-Road. Unlike SOAP that is a protocol with a detailed specification, REST is an architectural style consisting of the best practices and guidelines. Instead of talking about REST in general it should be defined in more detail what does supporting REST actually mean – in the X-Road’s case a loose definition would be supporting JSON and/or XML over HTTP. Obviously, more detailed guidelines regarding the API provided by the X-Road will be defined during the next steps of the process.
Another hot topic was service descriptions of REST services. The discussion was about the technique or language used for producing the descriptions and if service descriptions should be optional or mandatory. The current idea is to produce REST service descriptions using the OpenAPI Specification (OAS), but more insights about different alternatives was requested by the participants. REST service descriptions should be mandatory just like SOAP service descriptions currently are. Their role is essential for a service consumer and their quality can make a huge difference on a time that is required for implementing a client application consuming the service. Till what extent the X-Road will validate the content of service descriptions, will be defined later.
REST support implementation alternatives
In the beginning of the second part two alternative basic implementation approaches were presented to the participants whose task then was to comment on them and/or present their own ideas and visions. In addition, a list of open issues to consider was given to the participants as an input for the assignment, e.g. how query parameters are handled, how HTTP headers are handled, how to transfer X-Road specific request/response data, which parts of the message must/should be signed etc.
Image 2. Current security server architecture (simplified).
The first approach was about adding an additional rest proxy component to the security server that just wraps REST messages inside SOAP. This approach does not require changing the X-Road transport message protocol, but it adds more overhead to REST messages compared to SOAP.
Image 3. Approach 1 - additional REST proxy component.
The second approach was about changing the X-Road message transport protocol to support generic message payloads instead of the current SOAP payload. This approach makes it easier to support other message formats in the future and it also makes processing REST messages faster compared to SOAP, but it requires major changes to X-Road transport message protocol and many existing key components.
Image 4. Approach 2 - changes to the X-Road message transport protocol.
The assignment generated many new ideas and approaches. Some groups used one of the two presented alternatives as a starting point and then there were groups that defined their own approach from clean table. Some approaches required changes to existing security server proxy components and others were based on adding new components and a parallel communication channel between security servers. The most radical idea was to implement security server as a software library and redesign the X-Road communication model. However, two things were commonly agreed: 1) REST support should be native and implemented on the transport protocol level and not wrap REST messages inside of SOAP and 2) the changes must be backwards compatible and they should not affect existing SOAP services.
Next generation X-Road
In the beginning of the third part the NIIS technical roadmap for 2018 and some possible future enhancement ideas were presented. Then it was the participants turn to share their vision regarding the future of the X-Road.
The main theme was to make the use of the X-Road easier and streamline both member and security server registration process. Developers were not forgotten either - a developer version of the security server that can be set up in minutes and that does not require registration was discussed too.
When it comes to the technology, supporting containers and better support for cloud platforms were on top of the wish list. Blockchain – a technology that the X-Road is not based on or that is does not currently use internally – was also discussed as an alternative for distributing global configuration. In addition, possibility to join the X-Road using a custom endpoint based on a software library implementing the required protocol stack instead of the official security server software package was discussed too.
To summarize, the next generation X-Road should be a well maintained and interoperable, platform independent solution.
What next?
The outcome of the workshop exceeded the expectations clearly. The workshop provided active discussion, intensive group working, fresh ideas and valuable input for the next phase of the planning process. A big thanks to all the participants.
The NIIS will continue planning in more detailed level, based on the input received from the workshop. New blog posts regarding the topic and the next steps will be published during the next months.