SOAP, being a mature technology, has an extensive and often differently interpreted standard set. This makes it an excellent tool for corporate users to manipulate data into their precise requirements and technology stack. However, for public consumption, this causes issues that sometimes are difficult or impossible to solve without changing code. A good example here is that SOAP is allowed to define the same type in some standard interpretations in different XSD files. However, when trying to use this in other interpreters, it will most likely crash.
To solve this, we need to look at SOAP a little bit deeper. In essence, SOAP, as a technology, is simply a Web (or HTTP) POST call with a specifically formatted XML payload, which the SOAP server is expecting and understands. It then returns a specifically formatted XML response which the client then can parse and use.
You might be saying, ‘Hey, that sounds very much like a REST call,’ but that is exactly what it is. Instead of an API reference, which gives you the Request and Response formats and requirements, SOAP publishes a WSDL. So if you’ve got one of these SOAP Services which breaks standards, if you can get the text of a successful Request, you can use REST to make the call with that request body. To show you how this works, I will use a free SOAP web service that works with countries. I will use Linx, a low-code dev tool, to do this.
Linx uses .NET services to call SOAP services, following the .Net defined standards. This means that there would be SOAP services out there that would not work with Linx directly, as they would break the .NET standards for SOAP.
This example works fine with the SOAP Plugin, but to show the REST option, let’s imagine that it will break, and we need to use REST to call it.
- WSDL URL: http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService.wso?wsdl 1
- Service URL: http://webservices.oorsprong.org/websamples.countryinfo/CountryInfoService.wso
First, we’ll use a tool like SoapUI or Postman to try and get a successful call. Alternatively, if you are already given a successful payload, like in this example, you can use that (Example Documents for CountryInfoService).
To get started, add a new SOAP Project to SoapUI and add the WSDL. We first test if SoapUI gets a successful response back. SoapUI Screenshot of the required payload (SoapUI gave us ? parameters, which we just changed to logical values) and a successful response:
Now we can set up Linx with a CallRESTWebService function and call the SOAP service.
Note: Sometimes, as in this example, the SOAP server requires specific Content-Types. Use your successful call from SoapUI to find these instances. In this example the SOAP server wanted a content type of ‘text/xml;charset=UTF-8’ and did not accept the default ‘application/xml’. So we just added in a Header to overwrite the content type.
So in summary, in the screenshot above you can see that we used the ‘CallRESTEndpoint‘ function to call the SOAP Web service. You can now easily extend this process to any of your other target systems.
Here’s the Linx Solution: CallSOAPwithREST.lsoz (5.4 KB).