Layer 7 API Management

REST-to-SOAP Remapping 

07-18-2014 06:51 PM

Using a SOA or API gateway like the CA API Gateway to perform REST-to-SOAP transformation at runtime is trivial to setup. With the CA API Gateway in front of any existing Web service (in the DMZ, for example), you can virtualize a REST version of this same service. Using an example, here is a description of the steps to perform this conversion.

 

Imagine the geoloc Web service for recording geographical locations. It has two methods, one for setting a location and one for getting a location. See below what this would look like in SOAP.

 

Request:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <geo:getPosition xmlns:geo="http://test.layer7tech.com/geolocws">
      <geo:trackerId>34802398402</geo:trackerId>
    </geo:getPosition>
  </soapenv:Body>
</soapenv:Envelope>

 

Response:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <geo:getPositionRes xmlns:geo="http://test.layer7tech.com/geolocws">
      <geo:latitude>52.37706</geo:latitude>
      <geo:longitude>4.889721</geo:longitude>
    </geo:getPositionRes>
  </soapenv:Body>
</soapenv:Envelope>

 

Request:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <geo:setPosition xmlns:geo="http://test.layer7tech.com/geolocws">
      <geo:trackerId>34802398402</geo:trackerId>
      <geo:latitude>52.37706</geo:latitude>
      <geo:longitude>4.889721</geo:longitude>
    </geo:setPosition>
  </soapenv:Body>
</soapenv:Envelope>

 

Response:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <geo:setPositionRes xmlns:geo="http://test.layer7tech.com/geolocws">OK</geo:setPositionRes>
  </soapenv:Body>
</soapenv:Envelope>

 


Here is the equivalent REST target that I want to support at the edge. Payloads could be XML, but let’s use JSON to make it more interesting.

 

GET /position/34802398402

 

HTTP 200 OK
Content-Type: text/json

 

{
  'latitude' : 52.37706
  'longitude' : 4.889721
}

 

POST /position/34802398402
Content-Type: text/json

 

{
  'latitude' : 52.37706
  'longitude' : 4.889721
}

 

HTTP 200 OK

 

OK


Now let’s implement this REST version of the service using the CA API Gateway. I’m assuming that you already have a Gateway deployed between the potential REST requesters and the existing SOAP Web service.

 

First, I will create a new service endpoint on the gateway for this service and assign anything that comes at the URI pattern /position/* to this service. I will also allow the HTTP verbs GET and POST for this service.

 

REST geoloc service properties

 

Next, let’s isolate the resource id from the URI and save this as a context variable named ‘trackerid’. We can use a simple regex assertion to accomplish this. Also, I will branch on the incoming HTTP verb using an OR statement. I am just focusing on GET and POST for this example but you could add additional logic for other HTTP verbs that you want to support for this REST service.

 

Regex for REST service resource identification

 

Policy branching for GET vs POST

 

For GET requests, the transformation is very simple, we just declare a message variable using a SOAP skeleton into which we refer to the trackerid variable.

 

SOAP request template

 

This soap message is routed to the existing web service and the essential elements are isolated using XPath assertions.

 


Processing SOAP response

 

The REST response is then constructed back using a template response.


Template JSON response

 

A similar logic is performed for the POST message. See below for the full policy logic.

 


Complete policy

 

You’re done for virtualizing the REST service. Setting this up with the CA API Gateway took less than an hour, did not require any change on the existing SOAP web service and did not require the deployment of an additional component. From there, you would probably enrich the policy to perform some JSON schema validation, some URL and query parameter validation, perhaps some authentication, authorization etc.

Statistics
0 Favorited
9 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

03-13-2019 03:17 PM

Does anyone have an example how to do SOAP-to-REST mapping ? 

 

Can we use "Publish SOAP Web Service Wizard and provide "Custom resolution path" like /employees/*?

 

It seems not working this way as there is no hit into /employees at all.

 

Any comment how to do REST-to-SOAP Remapping in CA 9.4 Gateway?

10-21-2017 07:53 PM

Hello

 

This particular screen is a picture of the beginning wizard of publish a webAPI:

 

 

 

If your going to publish a restful service you can use the above wizard to create the URL and then build policy within it.  Like the following.

 

The gateway here now has a service listening on http://gateway_url:8080/rest2soap/.  If the incoming request url comes in with the following:

 

/rest2soap/travel?startingpoint=Vancouver&destination=Toronto

 

The we can use our assertion language to parse the departure and arrival parameters and then insert those into a soap service, like this:

 

 

 

 

First, set a context variable for the destination and startingpoint parameters.  Call them destination and startingpoint, so that its easier to reference later on in policy.

 

Set up the a if / then scenario with comparing the uri:

 

 

-          Compare if uri = travel, which points to soapaction of voonairreservationdetails  - A specific soap message that’s highlighted above.

 

-          Or compare if uri = deals, which points to soapaction of vooanairreservations – A different message than the above.

 

Then When you route to your soap backend, you can highlight the message variable that you set above.

 

 

 

 

On the response back to the client you can use several different approaches to transfer the message from a soap message to json, if needed:

 

 

-          Evaluate Response Xpath

 

-          Apply XSLT

 

-          Apply JSON transform

 

Does this help?

 

Regards,

 

 

Derek Orr

ca technologies

Principal Consultant, CA API Management Presales

m: 778-980-0029

Email = Derek.Orr@ca.com<mailto:Derek.Orr@ca.com>

 

CA API Management Community: https://communities.ca.com/community/ca-api-management-community

10-20-2017 06:07 PM

Unfortunately, these instructions no longer seem to work with the 9.2 gateway.  This is a problem since the 9.2 gateway documentations, which provides very little else in the way of how-to's or samples, still makes reference to this tutorial.  The  "Regular Expressions Screen" depicted above is more simplified than what comes with 9.2, and the using the inputs shown above result in an unhelpful "Internal Server Error" when the policy runs.  If this commend is viewed by CA support, please provide an updated tutorial for users who are still purchasing your products.  

01-01-2017 05:41 AM

Very nice instruction. It would be interesting to see how this would work with a more complex service where you have much more than 2 elements to work with. The Apply JSON transformation assertion could play a role here, but it would be very useful to have a example which shows how to do this and get the correct message format for the SOAP service. In particular the namespace has always been a issue in cases I have seen.

02-25-2015 11:35 AM

When you inject the values in to the soap XML, how are you/how would you ensure that the value that is being injected is properly escaped XML? If we were inserting text values, it is likely that it will contain invalid xml characters.

11-11-2014 04:00 AM

We should have a way to directly map values from client requests to Backend Soap requests.

Related Entries and Links

No Related Resource entered.