REST-to-SOAP Remapping

    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 - Layer 7 Technologies


    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 - Layer 7 Technologies


    Regex for REST service resource identification

     

     

    Policy branching for GET vs POST - Layer 7 Technologies


    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 - Layer 7 Technologies


    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 - Layer 7 Technologies


    Template JSON response

     

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

     

     

    Complete policy using SecureSpan - Layer 7 Technologies


    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.