Ha, I expected it to be about SOAP the protocol https://en.wikipedia.org/wiki/SOAP but this seems to be more interesting. I suppose if you have a Galactic Empire sized business, maybe something like SOAP (or EDI) to really nail things down makes some sense. Otherwise I'm not so sure.
Not a year goes by where I’m not convinced that things would be easier if as a community we used a modern version of the soap protocol, maybe with JSON instead of XML. RPC is such a clean design compared to REST, and it we had auto-generated client code 15 years ago, something the likes of swagger are still catching up with.
I found a great book at Safari Books Online on SOAP that said that it was written because the author had been bitten by those issues and other things caused by some less than brilliant decisions on the part of those who made the SOAP standard (he was considerably less polite than I have phrased it) and wrote the book so the rest of us didn't have to waste as much time figuring it out as he had.
I don't remember the name of the book or the author, and when I needed a SOAP book a couple years after that it did not show up when I searched.
At one point I got tired enough of the quirks of making servers work with clients not using the server's client generator that I wrote a little proxy that would sit between the server and client. Then I'd write a client using the server's client generator that would just go through all my services and log the communications.
For example lets say I had a server to look up VAT, which takes a sales price and a country code and returns the VAT rate and the VAT amount.
I'd do that through the proxy two or three times, which would save the XML the client sent to the server and the XML response. I'd then compare the XML from the different client requests to see if anything changed, such as timestamps.
I'd then open the client XML in an editor, replace any timestamps with "___TIMESTAMP___", then search for the price and country code to see how those were stored. I'd replace them with "___PRICE___" and "___COUNTRY__".
For the XML from the server, I'd open that in an editor and search for VAT rate and amount. For those I'd figure out a regular expression that could find them.
Then on the client I could dispense with using a SOAP library. When I wanted to look up VAT I'd just use the normal HTTP library of the client language, using the edited client XML as a template. I'd use the normal string or regex client library to replace "___TIMESTAMP___", "___PRICE___", and "___COUNTRY___" with the correct values, send the XML to the server, then use the regex to pull the answers out of the response.
From there it was a simple matter to make a library to handle this. Input was the client XML template, URL of the server, and a list of name => value pairs, and a list of name => regex pairs. It would look for "___name___" in the template for each input name and replace it with its value, call the server, and then for each name in the second list, use the corresponding regex to find the result, and return a list of name => value pairs with those results.
It was a bit tedious. If someone deployed a new SOAP service I had to go generate a client using the same SOAP implementation the server used, call the new service from that through my proxy to get the XML for the templates, and then make a template and the extraction regexes, but it was still usually less hassle than mixing server and client SOAP implementations.