It was just a bad SOAP api. You can write a bad and cumbersome REST api as well if you want, and MS would certainly be capable of doing so. SOAP is not really the problem here.
SOAP is the problem here. Specifically, it's the architectural decision to hide the protocol details which inevitably ends up biting everyone who uses it, because it's a textbook leaky abstraction.
"Specifically, it's the architectural decision to hide the protocol details which inevitably ends up biting everyone who uses it"
Sorry I don't agree.
Firefox for example hides the protocol details. You don't need to know DNS, TCP/IP, HTTP to browse the web.
It's the same for SOAP. If with "hide the protocol details" you refer to this part of the post
"I got an error. Not a descriptive error, or an HTTP status code, or anything that could be used to track down the problem but a “SOAP Error.”"
you may not be aware that the SOAP specification has SOAP exceptions. And they are actually quite easy:
<soap:Fault>
<faultcode>soap:Client</faultcode>
<faultstring>Please specify your birth date</faultstring>
</soap:Fault>
He just used a bad SOAP api that returned an useless error.
There are many other things about SOAP we can hate and that need to be fixed, but in this particular case SOAP is not at fault, and REST could very well be exactly as bad.
> Firefox for example hides the protocol details. You don't need to know DNS, TCP/IP, HTTP to browse the web.
I don't think that example supports your argument. Quite the reverse, in fact. Firefox doesn't hide that much of the details. You can still see the gory details of URLs and HTTP requests surfaced quite clearly, and the experience of using the web is that much richer if you know what they are and how to manipulate them. Firefox doesn't actively prevent you from doing so if you want to, which it would if it was trying to present a sealed abstraction.
As regards errors and error reporting, I don't particularly want to get into REST v SOAP, because that's tired ground that's been trodden a thousand times over. However, REST has an advantage over SOAP here in that it uses HTTP error codes. An app which returned a 200 response when it couldn't find something would never be described as RESTful, whereas a SOAP app can get away with anything as an error response. It's simply not possible for a REST API to be bad in that sense where it demonstrably is for SOAP.
>Firefox doesn't hide that much of the details. You can still see the gory details of URLs and HTTP requests surfaced quite clearly, and the experience of using the web is that much richer if you know what they are and how to manipulate them. Firefox doesn't actively prevent you from doing so if you want to, which it would if it was trying to present a sealed abstraction.
Contrast with IEs 'friendly' error messages by default. Instead of an easily diagnosed 'page not found', or 'address not found', or 'server error' you get 'something went wrong' and then a list of always incorrect guesses as to what the problem might be and a confusing list of irrelevant things you can try to 'fix' the problem. I bet somebody got a bonus for that feature.
Most of the OP's problem was the fact that there was no simple way to JUST INSPECT the soap messages going back and forth. You can say that is more a problem of his tools than SOAP. But then XML (and especially SOAP) is so friggin' ugly that of course toolmakers are going to want to abstract into invisibility.
That said, SOAP really is more complex than it needs to be. What makes it worse the ironic name : "SIMPLE object access protocol".
While this problem was for sure exacerbated by a bad API design (and I've seen pretty horrific REST ones as well) the fact that all of the underpinnings are abstracted away makes it very difficult to debug in any sort of depth when things go wrong. That's the ultimate point I was getting at - I'm fairly new to blogging so it is very possible I'm not conveying my point as effectively as I'd like.
As I understand it it's not a problem of the API but the nightmare of layers upon layers upon layers together with the promise that this will be hidden from you. (Not that having to fumble out what that REST service is actually sending back to you sounds that promising)
But the last three SOAP services I had to swallow ..err.. consume, leaked their abstraction over my desk and I had to start to xpath my way through responses from a Java service after having curl'ed my handwritten requests to the other side. This was not due to a problem with the published API but with the protocol annoyances as such. (e.g.: your OrderClass is not my order_class and your Array() is not my [] )
