How to convert from REST to SOAP
Originally published on http://www.soatothecloud.com/2008/11/how-to-convert-from-rest-to-soap.html, on Friday 14th November 4th 2008, by Mark O’Neill, CTO at Vordel
The popular advantages of REST over SOAP are well known: It’s easier to write a REST client, the messages are smaller, you can cache REST traffic using standard Web infrastructure. But what if you have SOAP Web Services and your clients are crying out for REST Web Services instead?
Here is how you create REST Web Services in front of SOAP services using Policy Studio and the Vordel XML Gateway…
To do this, create a policy which reads parameters from the REST URL and then inserts those parameters into a SOAP message which it creates on-the-fly. This is shown in the screenshot below:
Let’s look at one of the filters which retrieve’s parameters from the REST request. This is added to the policy by dragging and dropping it from the “attributes” group (a REST parameter is an example of a message attribute).
Once the attributes are read in from the REST request, we create a SOAP message using a “Set Message” filter, as shown below. The message attributes are written dynamically into this SOAP message which is created on-the-fly. You can see the message attributes below, with the dollar signs and curly braces:
The upshot is that now a REST client, such as an XMLHttpRequest object running in a browser, can access a URL like this http://xmlgateway:8080/QuotationRequest?CustomerID=1234&CommencementDate=Jan2008 and then this results in the XML Gateway sending a SOAP request to a Web Service which looks like this:
<soap:envelope soap=”http://schemas.xmlsoap.org/soap/envelope/”>
<soap:body>
<m:getquotation m=”http://www.example.org/”>
<customerid>1234</customerid>
<commencementdate>Jan2008</commencementdate>
</m:getquotation>
</soap:body>
</soap:envelope>
The overall picture is shown below:
This is a nice example of “service virtualization”. The REST service in this example is a “virtual service”, since it doesn’t actually exist on the Web Service platform itself. Only the SOAP service exists there. The XML Gateway exposes the REST service as a “virtual service”. This has security advantages, since there is nothing so secure as something which doesn’t even exist. The REST service does not exist on the Web Services platform. It only exists on the locked down, hardened XML Gateway as a virtual service.
The REST parameters can be scanned using a “Threatening Content” filter dragged into the policy in Policy Studio. This is shown below:
In addition, authentication can be added, for example using HTTP client authentication or SSL mutual authentication.
Using this technique, clients can access a REST service, gaining the advantages of REST, while the service provider is safe in the knowledge that they haven’t just opened up a backdoor into their SOAP services.
