This is great. My (so far, only) experience with SOAP started when my boss asking me to investigate the new version of a (very big) vendor's SOAP API. Support for the old version of the API was being dropped in a few days.
It turns out that our framework has SOAP built in, so I had it suck in the WSDL and make a sample request. It was rejected with a generic error. As it turns out, our framework was generating requests that looked like this (simplified with much SOAP nonsense stripped out):
the difference being that our framework declares a "default namespace", while their API expected a "namespace prefix". As far as I could tell from reading the spec (always a bad sign when you're using a standard that both ends support) the difference shouldn't matter.
- - -
I went to my boss. He showed me the old code; all the requests it needs to make are hardcoded based on the docs, and substitute XML-encoded variables in the right places.
Save a few minor changes, that's the process we still use today, and it fucking works.
Something's seriously messed up if, once the XML has been parsed, their code can even tell the difference between those two constructs, much less care.
It turns out that our framework has SOAP built in, so I had it suck in the WSDL and make a sample request. It was rejected with a generic error. As it turns out, our framework was generating requests that looked like this (simplified with much SOAP nonsense stripped out):
…and the requests in the API documentation look like this: the difference being that our framework declares a "default namespace", while their API expected a "namespace prefix". As far as I could tell from reading the spec (always a bad sign when you're using a standard that both ends support) the difference shouldn't matter.- - -
I went to my boss. He showed me the old code; all the requests it needs to make are hardcoded based on the docs, and substitute XML-encoded variables in the right places.
Save a few minor changes, that's the process we still use today, and it fucking works.