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.

Below is how to implement this technology in Linx, a low-code platform for backends.

Background - https://linx.software/soap-to-rest/
Linx solution - https://community.linx.software/community/uploads/short-url/nN1SP5FaN36GUZY9aPCjNbnh7SL.lsoz