REST/Json conversion to SOAP

[kakoni]

So is the current plan to wrap rest/json request inside SOAP request?( as per this image https://github.com/educloudalliance/xroad-rest-gateway/blob/master/images/rest-soap.png)?

[lhotari]

You know, it's like the russian wooden dolls, https://www.youtube.com/watch?v=Qk_ylpgfNTg . :)

[petkivim]

Basically there are three alternative approaches when it comes to JSON. Let's say that we have a very simple JSON string like the one below.

{"key":"value"}

• Conversion from JSON to XML.

<response>
  <key>value</key>
</response>

• Wrapping JSON inside XML element (no conversion to XML).

<response>
  {"key":"value"}
</response>

• Sending JSON as SOAP attachment.

Currently we're mainly concentrating on the first one, conversion from JSON to XML.

[lhotari]

IBM's JSONx is featured on dailywtf.com: http://what.thedailywtf.com/t/ibms-jsonx-or-how-to-represent-json-in-xml/3972 Old HN news item: https://news.ycombinator.com/item?id=2498834

It seems that the use case for JSONx was to wrap JSON in SOAP. Without such a solution you will loose type information that is present in JSON. That's a fact and JSONx solves it. The twitterverse thinks this is a good joke: https://twitter.com/search?q=jsonx&src=typd

[petkivim]

We don't want to loose the type information that's present in JSON and JSONx seems to resolve that problem. I have to admit that I hadn't heard of it before.

X-Road requires that all the services have a WSDL description that contains the schema definition of request and response messages, and this applies to REST/JSON services too. This means that the type information that's present in JSON is placed in the WSDL description. The ideal solution would be to auto-generate the WSDL from REST API's service description, e.g. RAML. This, of course, requires that REST APIs have a service description and that RAML->WSDL conversion is possible (we're currently looking into that).

[andreskytt]

There are two distinct issues here: access to existing SOAP APIs via REST/JSON and accessing existing REST/JSON things via SOAP. The former is not that complex but the latter needs more thought. How large is the legacy REST/JSON base and what is the quality of the RAML descriptors? If the legacy is small, can we maybe require that the API is defined on class level from which suitable WSDL or RAML descriptors be generated?

[andreskytt]

After a bit more thought, it seems there is a need for a more explicit set of requirements to be agreed upon. Making a start here, probably should be moved somewhere more appropriate:

• It must be possible to access legacy WSDL-defined x-road services via rest/json. It is not necessary to generate RAML from WSDL
• It must be possible to access rest/json services via WSDL-defined x-road services.
• WSDLs in the security server must match the actual service to facilitate service discovery (i.e. an "execute REST with payload" is not an OK x-road service)

[lhotari]

@andreskytt indeed there is another issue "How to collect use cases" #2 . Any ideas for that?

[lhotari]

REST should support resource links. That would enable to do HATEOAS style of integrations.

HATEOAS style is very contrary to the fixed interface style that SOAP/WSDL represents. Is this a problem?

[kakoni]

@lhotari Linking is interesting case, you need to do link reformatting on consumers proxy-server in order for it to work. I guess simple regex might work.

Example

HTTP/1.1 200 OK
{
  "href" : "https://api.karri.com/v1/users?offset=50&limit=50"
  "offset": 50,
  "limit": 50,
  "first": {
      “href”: "https://api.karri.com/v1/users"
  },
   "prev": {
      “href”: "https://api.karri.com/v1/users"
  }
}

would be reformatted using (s/api.karri.com/gw.finland.fi\/api.karri.com/g) as

HTTP/1.1 200 OK
{
  "href" : "https://gw.finland.fi/api.karri.com/v1/users?offset=50&limit=50"
  "offset": 50,
  "limit": 50,
  "first": {
      “href”: "https://gw.finland.fi/api.karri.com/v1/users"
  },
   "prev": {
      “href”: "https://gw.finland.fi/api.karri.com/v1/users"
  }
}

Obvious downside is that complexity of the proxy solution rises...

[petkivim]

@kakoni, thanks for the idea. Reformatting is implemented in Consumer Gateway in version 0.0.2. This implementation works as long as all the resource links and the service have the same base URL.

After downloading and installing v0.0.2 you can try the features like this (the response contains links to other resources that are reformatted by Consumer Gateway):

[GET] http://localhost:8080/RESTGateway/Consumer/avoindata.prh.fi/opendata/bis/v1/?totalResults=false&resultsFrom=0&name=asunto&companyRegistrationFrom=2014-02-28

[kakoni]

Implement in the client. Closing.