6 ms·

SOAP is a nightmare. soapUI is an application that will let you fiddle around until you get the calls right. I recently did exactly this. I wound up not only

SOAP is a nightmare. soapUI is an application that will let you fiddle around until you get the calls right. I recently did exactly this. I wound up not only generating the SOAP envelope by hand but also the HTTP headers: SOAPAction: "http://...//SubmitDataform http://...//SubmitDataform What is the action I am trying to do doing in the HTTP headers?

ollysb 16y ago
It's this lack of discoverability that kills SOAP. I've never had any trouble parsing the response xml once I get my hands on it, namespaces etc are a non issue at this point. The completely non-standard format of the queries that makes it such hard work. With REST you just have to figure out a url. With soap you have to do that plus work out how authorization is handled, how to embed the procedure and parameters and then what namespaces to put everything in.
- pak 16y ago
  A good SOAP library lets you plug in a WSDL and returns an API object with all the methods of the webservice. There is literally no equivalent capability for REST. You shouldn't be doing any of the things you describe by hand. You are vastly oversimplifying when you say "with REST you just have to figure out a URL". Try integrating with a service that takes only custom HTTP verbs with multipart/form-data but because there's no standard way to send an array in HTTP you have to append some parameter multiple times but in the right order. There's some vague attempt at using OAuth for authentication, but it doesn't work with any of the libraries you are used to. Oh, and the service returns a 503 some of the time, which (according to the rambling hacked up docs for this API) means you should retry your request in 10 seconds. No, it's not always trivial.
  - ollysb 16y ago
    You're right that in theory a REST api could also be a PITA to use. In my experience though I've always been able to get the query I wanted quickly and easily. To be fair it's rare that I'm doing anything that isn't a GET but on the occasions where I have wanted perform an update It hasn't resulted in any of the difficulties you mention.
- trezor 16y ago
  It's this lack of discoverability that kills SOAP I thought it was discoverability which was SOAP's strong point, while ad-hoc solutions like REST which have the bonus of being much more lightweight/terse, lacks this feature. As for non-standard query-format, with a good toolkit you point to the WSDL and you are done, all your RPC-calls pregenerated for you. I know SOAP has some issues, that it's a verbose line-format and that recent WS*-additions add complexity faster than you can say "oh shit", but at its root, SOAP really isn't hard to work with if you have a decent toolkit. If you are hand-rolling your SOAP-layer, you might as well start invoking your database trough telnet and handrolled protocol-code. It makes as much sense.
  - regularfry 16y ago
    If the REST architecture is sufficiently mature, it should be entirely discoverable, and in a much more granular fashion than SOAP, without any tool more complex than curl. That's what HATEOS is all about. The difficulty is that saying that an interface is RESTful doesn't guaranee that: there's no naming difference between a service at level 3 on the Richardson Maturity Model, where this does apply, and one at level 1, where you can't even rely on HTTP verbs behaving predictably. As to the existence of sufficiently good toolkits, that won't save you in the face of vendor bone-headedness. Talking to .NET from a Java stack is still problematic, where either toolkit on its own is apparently fine on its own territory. There's a particularly fine example in MS Exchange Web Services, where getting Java to talk to it over SOAP is so fiddly they're releasing a Java port of their managed API.
    - trezor 16y ago
      To be fair Exchange Web Services is a prime example (IMO) of how not to do SOAP. It's the philosophy of SOAP being "message-passing" taken to the extreme. You have the SOAP messages which envelopes (sigh) yet another message-level architecture where every request, even at OO level means constructing request-objects with millions of sub-properties, all types fitting an abstract inheritance tree. Which ofcourse is also what you get returned after sending your request. So then you have to start analyzing your response object (again a message-object enveloped in a SOAP-message) and anaylze what class it actually is and the same for all subproperties. I don't mind SOAP so much, but EWS can really go die in a fire. You can say whatever you want about SOAP in general, but EWS cannot really be used as an example of anything other than itself. I've never seen such a painful and convoluted solution anywhere else. Even if SOAP had been ditched and the wire-format used had been some sort of RESTFul implementation, it would still be a clusterfuck to use. Blaming SOAP here is IMO a bit misdirected.
pak 16y ago
You Are Doing It Wrong. Anybody that tries to interface with a SOAP interface by writing envelopes by hand is wasting their time and half-implementing the (long, terrible, complicated, blah blah) spec. Find a good toolkit. Yes, the protocol is way over engineered but good tools can and do abstract that all from you. For instance, PHP's standard library lets you plug in a WSDL URL and consume SOAP services in two lines of code. (And because it is a good toolkit, it lets you spit out all traffic with one debug flag, unlike whatever terrible thing the author of this article is using.) Most of what people complain about in these comments would be moot with good tools. You would probably complain about REST if you didn't have curl or Firebug and had to telnet all your test calls--that's equivalent to what most people here seem to be doing.
- route66 16y ago
  I don't know what wsdl's you were dealing with, but I met a fair amount of them who were not consumable by neither php-soap, python and even a java client while trying to read a .net one. The reason people are writing their own envelopes in cases (like I did also) is because the tooling is not delivering up to it's promises. (Let alone that the server might not even understand the two-line-code genertated nusoap reponse because he interpretes some ws-* rules about namespaces differently. The conclusion is: nobody wants to write his/her own envelopes.
  - kaylarose 16y ago
    Every time I here about regular Soap clients failing, it's always in regard to trying to consume a .NET service. I don't know anything about .NET, but I wonder if there is something profoundly different that is going on behind the scenes, or does it just generate crufty WSDLs? Can anyone shine more light on this?
    - route66 16y ago
      My problems were in fact with Java web services. There are different interpretations possible of the recent SOAP standards (or non-standards, as some are more de-facto than ratified) of smaal details as where to put type-info in the wsdl and if it is allowed to be redundant. This way sensible tooling is defied. Serving and consuming smaller services with light messages and shallow structure works mostly out of the box. The going gets rough when people put half their strongly typed domain logic in the wsdl which has to be recereated on the other side. Hint: Collections != Arrays != Hashes So, problaby not .NET but bloat related. Interoperability is a problem on all sides though.

ollysb 16y ago

It's this lack of discoverability that kills SOAP. I've never had any trouble parsing the response xml once I get my hands on it, namespaces etc are a non issue at this point. The completely non-standard format of the queries that makes it such hard work. With REST you just have to figure out a url. With soap you have to do that plus work out how authorization is handled, how to embed the procedure and parameters and then what namespaces to put everything in.

pak 16y ago
A good SOAP library lets you plug in a WSDL and returns an API object with all the methods of the webservice. There is literally no equivalent capability for REST. You shouldn't be doing any of the things you describe by hand. You are vastly oversimplifying when you say "with REST you just have to figure out a URL". Try integrating with a service that takes only custom HTTP verbs with multipart/form-data but because there's no standard way to send an array in HTTP you have to append some parameter multiple times but in the right order. There's some vague attempt at using OAuth for authentication, but it doesn't work with any of the libraries you are used to. Oh, and the service returns a 503 some of the time, which (according to the rambling hacked up docs for this API) means you should retry your request in 10 seconds. No, it's not always trivial.
- ollysb 16y ago
  You're right that in theory a REST api could also be a PITA to use. In my experience though I've always been able to get the query I wanted quickly and easily. To be fair it's rare that I'm doing anything that isn't a GET but on the occasions where I have wanted perform an update It hasn't resulted in any of the difficulties you mention.
trezor 16y ago
It's this lack of discoverability that kills SOAP I thought it was discoverability which was SOAP's strong point, while ad-hoc solutions like REST which have the bonus of being much more lightweight/terse, lacks this feature. As for non-standard query-format, with a good toolkit you point to the WSDL and you are done, all your RPC-calls pregenerated for you. I know SOAP has some issues, that it's a verbose line-format and that recent WS*-additions add complexity faster than you can say "oh shit", but at its root, SOAP really isn't hard to work with if you have a decent toolkit. If you are hand-rolling your SOAP-layer, you might as well start invoking your database trough telnet and handrolled protocol-code. It makes as much sense.
- regularfry 16y ago
  If the REST architecture is sufficiently mature, it should be entirely discoverable, and in a much more granular fashion than SOAP, without any tool more complex than curl. That's what HATEOS is all about. The difficulty is that saying that an interface is RESTful doesn't guaranee that: there's no naming difference between a service at level 3 on the Richardson Maturity Model, where this does apply, and one at level 1, where you can't even rely on HTTP verbs behaving predictably. As to the existence of sufficiently good toolkits, that won't save you in the face of vendor bone-headedness. Talking to .NET from a Java stack is still problematic, where either toolkit on its own is apparently fine on its own territory. There's a particularly fine example in MS Exchange Web Services, where getting Java to talk to it over SOAP is so fiddly they're releasing a Java port of their managed API.
  - trezor 16y ago
    To be fair Exchange Web Services is a prime example (IMO) of how not to do SOAP. It's the philosophy of SOAP being "message-passing" taken to the extreme. You have the SOAP messages which envelopes (sigh) yet another message-level architecture where every request, even at OO level means constructing request-objects with millions of sub-properties, all types fitting an abstract inheritance tree. Which ofcourse is also what you get returned after sending your request. So then you have to start analyzing your response object (again a message-object enveloped in a SOAP-message) and anaylze what class it actually is and the same for all subproperties. I don't mind SOAP so much, but EWS can really go die in a fire. You can say whatever you want about SOAP in general, but EWS cannot really be used as an example of anything other than itself. I've never seen such a painful and convoluted solution anywhere else. Even if SOAP had been ditched and the wire-format used had been some sort of RESTFul implementation, it would still be a clusterfuck to use. Blaming SOAP here is IMO a bit misdirected.

pak 16y ago

You Are Doing It Wrong. Anybody that tries to interface with a SOAP interface by writing envelopes by hand is wasting their time and half-implementing the (long, terrible, complicated, blah blah) spec. Find a good toolkit. Yes, the protocol is way over engineered but good tools can and do abstract that all from you. For instance, PHP's standard library lets you plug in a WSDL URL and consume SOAP services in two lines of code. (And because it is a good toolkit, it lets you spit out all traffic with one debug flag, unlike whatever terrible thing the author of this article is using.) Most of what people complain about in these comments would be moot with good tools. You would probably complain about REST if you didn't have curl or Firebug and had to telnet all your test calls--that's equivalent to what most people here seem to be doing.

route66 16y ago
I don't know what wsdl's you were dealing with, but I met a fair amount of them who were not consumable by neither php-soap, python and even a java client while trying to read a .net one. The reason people are writing their own envelopes in cases (like I did also) is because the tooling is not delivering up to it's promises. (Let alone that the server might not even understand the two-line-code genertated nusoap reponse because he interpretes some ws-* rules about namespaces differently. The conclusion is: nobody wants to write his/her own envelopes.
- kaylarose 16y ago
  Every time I here about regular Soap clients failing, it's always in regard to trying to consume a .NET service. I don't know anything about .NET, but I wonder if there is something profoundly different that is going on behind the scenes, or does it just generate crufty WSDLs? Can anyone shine more light on this?
  - route66 16y ago
    My problems were in fact with Java web services. There are different interpretations possible of the recent SOAP standards (or non-standards, as some are more de-facto than ratified) of smaal details as where to put type-info in the wsdl and if it is allowed to be redundant. This way sensible tooling is defied. Serving and consuming smaller services with light messages and shallow structure works mostly out of the box. The going gets rough when people put half their strongly typed domain logic in the wsdl which has to be recereated on the other side. Hint: Collections != Arrays != Hashes So, problaby not .NET but bloat related. Interoperability is a problem on all sides though.