40 ms·

Please drop the SOAP

121 points by thecoffman 16y ago

y0ghur7_xxx 16y ago
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.
- thecoffman 16y ago
  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.
- regularfry 16y ago
  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.
  - y0ghur7_xxx 16y ago
    "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.
    - regularfry 16y ago
      > 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. 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.
      - Waywocket 16y ago
        >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.
  - angdis 16y ago
    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".
- route66 16y ago
  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 [] )
  - y0ghur7_xxx 16y ago
    "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." So you actually used SOAP like REST with XML :)
    - nailer 16y ago
      Yes, but he didn't want to. If SOAP lived up to his expectations he's just be running autogenerated methods.
regularfry 16y ago
Urgh. I had exactly this experience trying to get the Exchange Web Services API to work. That's worse, because the author's solution, dropping any pretense at using a notionally "pluggable" API and just debugging with Wireshark, won't fly over HTTPS.
- mariusmg 16y ago
  Try it with Fiddler.Should work fine over https.
  - regularfry 16y ago
    No Windows boxes round these parts, or I would have. I tried WebScarab, but without the server certificate it was a lost cause (unless I missed a trick somewhere).
    - lmz 16y ago
      You have to generate a certificate for the proxy (WebScarab) and have the client trust it. The proxy will then act as a man-in-the-middle, presenting its own certificate to the client. See: http://www.owasp.org/index.php/Generating_Custom_SSL_Certificates_for_WebScarab http://www.owasp.org/index.php/Generating_Custom_SSL_Certifi...
      - regularfry 16y ago
        Now I know what to do if I ever find myself in that situation again. Thanks.
    - nailer 16y ago
      Charles proxy works on OS X and Linux.
  - icey 16y ago
    Thanks for the fiddler tip - I also use Wireshark for most of my debugging needs and https always causes problems.
wdewind 16y ago
People still use SOAP? Yikes, sorry.
- thecoffman 16y ago
  Sad part is its not just "People" Google's AdWords and Microsoft's AdCenter are both SOAP. Par for the course from Microsoft, but I'd expect better from Google.
  - nailer 16y ago
    Yeah, I have to work with the AdWords API and it sucks just as badly - the documentation also lags behind the implementation too. The super annoying thing is worrying about WSDL, XML namespaces and xpath for something as simple as getting a count of alerts.
    - robryan 16y ago
      Their client library is decent, for PHP anyway so you mostly get SOAP abstracted away. Up until you get an error then the usual problems are there. The underlying code in the client library is super bloated though, like what you would imagine from visual studio endpoint type stuff in the article. It may be that the core adwords developers are using Java and an old school SOAP interface makes sense to them. They certainly had a chance to change it recently with the new version.
      - nailer 16y ago
        in Python, they make you chose between ZSI and a beta soappy release. Their site has a getting started video which mentions running a config script they no longer distribute. most docs are using a different module name. Oauth isn't implemented at all. In JS, you have no client library so you're required to roll everything from scratch. PHP has oauth, more demo code and better docs, I've recently been using it to build a JS lib for a work project. The thing is, rather than maintain one client library, half maintain two others, and have a bunch of unofficial libraries, if they just made and documented a REST interface everyones lives would be easier.
asmithmd1 16y ago
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.
thecoffman 16y ago
edit: appears to be back and working fine. Embarrassing - despite my best efforts it appears as if my little linode couldn't handle being frontpaged - here's a cached entry for now: http://webcache.googleusercontent.com/search?q=cache:UehgGNUoeqUJ:thecoffman.com/2011/01/please-drop-the-soap/+http://thecoffman.com/2011/01/please-drop-the-soap/&cd=1&hl=en&ct=clnk&gl=us&source=www.google.com http://webcache.googleusercontent.com/search?q=cache:UehgGNU... The blog entry is cached as a static page hourly and served via nginx as such - this load shouldn't have killed it. Will be interesting to dive into.
mariusmg 16y ago
Actually the guy is actually complaining about consuming a WS from WCF (important distinction because consuming it using the default WS stack from .NET is a much better experience). Besides that...carry on praising REST.
rst 16y ago
One of the things in life I really regret is suggesting SOAP on a project. I thought it was just a packaged, somewhat elaborated version of a semi-reasonable XML-RPC type thing --- and worse, that the idea that it was standardized meant that you could count on some kind of half-decent interoperability. It was initially sold that way, but that was just the first of a parade of sales pitches, hilariously chronicled here, http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/ http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-... --- endlessly shifting as if seen through a fun-house mirror.
zakovyrya 16y ago
I'm pretty sure everybody read this piece: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
kleinsch 16y ago
Debugging SOAP stuff is a complete nightmare, but trying to figure out and implement somebody's RESTful API that has 100 different types of objects is also a hassle, since there isn't code generation that can help you. For tiny one-API-call tasks, I'd much rather use a JSON REST API that I completely understand. When I'm trying to interface with a complicated system that has a million different objects, I'd rather spend an hour figuring out the tools, then rely on generated code so I can take advantage of IDE auto-completion instead of digging through the documentation to remember the params and return value. It's the in-between of these two cases that's the devil, especially since big nasty APIs always start out small and simple.
mark_l_watson 16y ago
Diss on SOAP if you want but it does provide good error support for working with transactions in Java EE 6, ESB, etc. If you need to use infrastructure that works with SOAP, then use SOAP and stop whining. If you don't need to interop with existing systems that use SOAP, then sure, a REST style makes sense.
- famousactress 16y ago
  How does SOAP provide good error support? Maybe those frameworks do, but I don't see how SOAP is responsible... unless you're making the argument that XML is awesome for debugging because it's "Human Readable"... and that argument leaves me confused about what measure of humanity we're using.
- iramiller 16y ago
  Since the op is using WCF for calling the web service he would have a much easier time figuring out what is going on if he turned on WCF tracing. Every step in the pipeline including the messages sent on the wire and timings are available. Once you know the secret platform handshake these enterprise tools are pretty easy. Edit: fix annoying iOS auto-correction.
shimi 16y ago
Soap isn't really good, but its not just MS who pushed it. In the 90s it was endorsed by giants like IBM and Oracle
- thecoffman 16y ago
  Completely right - its not a Microsoft problem as much as its an "enterprise" problem. IT Managers love things like SOAP.
  - pak 16y ago
    And they should. It's easy to turn a WSDL into an exhibit for a contract, because it is a description of an API that can be converted to human readable and machine readable formats. There is no equivalent for REST, and most REST services have a loose interpretation of what it means to be "RESTful". Try doing serious, paid-availability integration with REST and watch the managers tear out their hair and the lawyers weep.
- RickRoll 16y ago
  Huh? Microsoft was on the committee and big parts of SOAP design came from MS's DCOM - the most widely used RPC toolkit at the time.
ericmsimons 16y ago
I have to say, REST is just a lot more straightforward than SOAP. Although there are numerous advantages with SOAP, I always cry myself to sleep at night when I find out that I have to use a SOAP API to complete a part of a project.
KevBurnsJr 16y ago
LOL, Wireshark. Nice.
famousactress 16y ago
The SOAP vs REST argument is a bit of a non-starter with me. SOAP is independently awful, and made worse by the fact that it's dependent on XML (which is awful), and RPC (which is at least not-always-awesome). REST vs RPC is a worthwhile discussion (they're at least both analogous), but I've seen plenty of REST/XML APIs that rival SOAP ones in ridiculousness. Then again.. I've never once experienced the inverse (a SOAP API that wasn't awful)... Consider context though. SOAP came about in a time when CORBA and DCOM were popular remoting strategies. Hard to fault folks thinking it was a big enough step forward :)
MindTwister 16y ago
SOAP in visual studio might be a pain, but its really not that difficult when working in PHP: http://php.net/manual/en/book.soap.php http://php.net/manual/en/book.soap.php I've implemented both servers and clients using SOAP with low to no hassles. Bad implementation != bad spec
praptak 16y ago
Not that I'm a big SOAP fan, but the author seems to be seriously confused: "For starters you have to point Visual Studio (sigh) to the service reference, at which point nine thousand (yes, that’s nine-zero-zero-zero) lines of code are generated." "Not a descriptive error, or an HTTP status code, or anything that could be used to track down the problem but a “SOAP Error.”" "Long story short, in order to inspect SOAP messages you have to write a class that implements the ICLientMessageInspector interface." These are supposed to be problems with SOAP? To me they look like a crappy implementation. The conclusion is also crappy: "In my mind SOAP’s biggest failure is what some people consider to be its biggest success – it abstracts away all notion of the underlying HTTP model and replaces it with crutches like code generation." Jeez, man - SOAP has problems, but code generation!? It's not a problem with SOAP but with the way your environment integrates with SOAP. Code generation over any protocol would create the same problems and there's nothing about SOAP that makes code gen inevitable.
koevet 16y ago
I don't like Soap for the same reasons everyone hates it. Having said that, in the Java space there are plenty of tools that turn the Soap experience into a bearable one. With CXF, for instance, is quite trivial to generate client code out of a WSDL file. The generator binds the request/response payload to Java beans so the developer doesn't have to understand the intricacies of the protocol. Debugging is also simple.
route66 16y ago
To give a slightly different spin to the discussion: does REST solve some of the problems SOAP addresses? First there was REST, now closely related to HATEOAS... I see the acronyms are coming. How to discover the meaning of data in the absence of a WSDL/RESTDL? Will we have microformats with links pointing to ontology-servers? Wat if its JSON? I wonder what REST looks like five years from now, when for instance, IBM and M$ become involved in a standardization process ...

121 points by thecoffman 16y ago

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.

thecoffman 16y ago
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.
regularfry 16y ago
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.
- y0ghur7_xxx 16y ago
  "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.
  - regularfry 16y ago
    > 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. 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.
    - Waywocket 16y ago
      >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.
- angdis 16y ago
  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".
route66 16y ago
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 [] )
- y0ghur7_xxx 16y ago
  "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." So you actually used SOAP like REST with XML :)
  - nailer 16y ago
    Yes, but he didn't want to. If SOAP lived up to his expectations he's just be running autogenerated methods.

regularfry 16y ago

Urgh. I had exactly this experience trying to get the Exchange Web Services API to work. That's worse, because the author's solution, dropping any pretense at using a notionally "pluggable" API and just debugging with Wireshark, won't fly over HTTPS.

mariusmg 16y ago
Try it with Fiddler.Should work fine over https.
- regularfry 16y ago
  No Windows boxes round these parts, or I would have. I tried WebScarab, but without the server certificate it was a lost cause (unless I missed a trick somewhere).
  - lmz 16y ago
    You have to generate a certificate for the proxy (WebScarab) and have the client trust it. The proxy will then act as a man-in-the-middle, presenting its own certificate to the client. See: http://www.owasp.org/index.php/Generating_Custom_SSL_Certificates_for_WebScarab http://www.owasp.org/index.php/Generating_Custom_SSL_Certifi...
    - regularfry 16y ago
      Now I know what to do if I ever find myself in that situation again. Thanks.
  - nailer 16y ago
    Charles proxy works on OS X and Linux.
- icey 16y ago
  Thanks for the fiddler tip - I also use Wireshark for most of my debugging needs and https always causes problems.

wdewind 16y ago

People still use SOAP? Yikes, sorry.

thecoffman 16y ago
Sad part is its not just "People" Google's AdWords and Microsoft's AdCenter are both SOAP. Par for the course from Microsoft, but I'd expect better from Google.
- nailer 16y ago
  Yeah, I have to work with the AdWords API and it sucks just as badly - the documentation also lags behind the implementation too. The super annoying thing is worrying about WSDL, XML namespaces and xpath for something as simple as getting a count of alerts.
  - robryan 16y ago
    Their client library is decent, for PHP anyway so you mostly get SOAP abstracted away. Up until you get an error then the usual problems are there. The underlying code in the client library is super bloated though, like what you would imagine from visual studio endpoint type stuff in the article. It may be that the core adwords developers are using Java and an old school SOAP interface makes sense to them. They certainly had a chance to change it recently with the new version.
    - nailer 16y ago
      in Python, they make you chose between ZSI and a beta soappy release. Their site has a getting started video which mentions running a config script they no longer distribute. most docs are using a different module name. Oauth isn't implemented at all. In JS, you have no client library so you're required to roll everything from scratch. PHP has oauth, more demo code and better docs, I've recently been using it to build a JS lib for a work project. The thing is, rather than maintain one client library, half maintain two others, and have a bunch of unofficial libraries, if they just made and documented a REST interface everyones lives would be easier.

asmithmd1 16y ago

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.

thecoffman 16y ago

edit: appears to be back and working fine. Embarrassing - despite my best efforts it appears as if my little linode couldn't handle being frontpaged - here's a cached entry for now: http://webcache.googleusercontent.com/search?q=cache:UehgGNUoeqUJ:thecoffman.com/2011/01/please-drop-the-soap/+http://thecoffman.com/2011/01/please-drop-the-soap/&cd=1&hl=en&ct=clnk&gl=us&source=www.google.com http://webcache.googleusercontent.com/search?q=cache:UehgGNU... The blog entry is cached as a static page hourly and served via nginx as such - this load shouldn't have killed it. Will be interesting to dive into.

mariusmg 16y ago

Actually the guy is actually complaining about consuming a WS from WCF (important distinction because consuming it using the default WS stack from .NET is a much better experience). Besides that...carry on praising REST.

rst 16y ago

One of the things in life I really regret is suggesting SOAP on a project. I thought it was just a packaged, somewhat elaborated version of a semi-reasonable XML-RPC type thing --- and worse, that the idea that it was standardized meant that you could count on some kind of half-decent interoperability. It was initially sold that way, but that was just the first of a parade of sales pitches, hilariously chronicled here, http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/ http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-... --- endlessly shifting as if seen through a fun-house mirror.

zakovyrya 16y ago

I'm pretty sure everybody read this piece: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple

kleinsch 16y ago

Debugging SOAP stuff is a complete nightmare, but trying to figure out and implement somebody's RESTful API that has 100 different types of objects is also a hassle, since there isn't code generation that can help you. For tiny one-API-call tasks, I'd much rather use a JSON REST API that I completely understand. When I'm trying to interface with a complicated system that has a million different objects, I'd rather spend an hour figuring out the tools, then rely on generated code so I can take advantage of IDE auto-completion instead of digging through the documentation to remember the params and return value. It's the in-between of these two cases that's the devil, especially since big nasty APIs always start out small and simple.

mark_l_watson 16y ago

Diss on SOAP if you want but it does provide good error support for working with transactions in Java EE 6, ESB, etc. If you need to use infrastructure that works with SOAP, then use SOAP and stop whining. If you don't need to interop with existing systems that use SOAP, then sure, a REST style makes sense.

famousactress 16y ago
How does SOAP provide good error support? Maybe those frameworks do, but I don't see how SOAP is responsible... unless you're making the argument that XML is awesome for debugging because it's "Human Readable"... and that argument leaves me confused about what measure of humanity we're using.
iramiller 16y ago
Since the op is using WCF for calling the web service he would have a much easier time figuring out what is going on if he turned on WCF tracing. Every step in the pipeline including the messages sent on the wire and timings are available. Once you know the secret platform handshake these enterprise tools are pretty easy. Edit: fix annoying iOS auto-correction.

shimi 16y ago

Soap isn't really good, but its not just MS who pushed it. In the 90s it was endorsed by giants like IBM and Oracle

thecoffman 16y ago
Completely right - its not a Microsoft problem as much as its an "enterprise" problem. IT Managers love things like SOAP.
- pak 16y ago
  And they should. It's easy to turn a WSDL into an exhibit for a contract, because it is a description of an API that can be converted to human readable and machine readable formats. There is no equivalent for REST, and most REST services have a loose interpretation of what it means to be "RESTful". Try doing serious, paid-availability integration with REST and watch the managers tear out their hair and the lawyers weep.
RickRoll 16y ago
Huh? Microsoft was on the committee and big parts of SOAP design came from MS's DCOM - the most widely used RPC toolkit at the time.

ericmsimons 16y ago

I have to say, REST is just a lot more straightforward than SOAP. Although there are numerous advantages with SOAP, I always cry myself to sleep at night when I find out that I have to use a SOAP API to complete a part of a project.

KevBurnsJr 16y ago

LOL, Wireshark. Nice.

famousactress 16y ago

The SOAP vs REST argument is a bit of a non-starter with me. SOAP is independently awful, and made worse by the fact that it's dependent on XML (which is awful), and RPC (which is at least not-always-awesome). REST vs RPC is a worthwhile discussion (they're at least both analogous), but I've seen plenty of REST/XML APIs that rival SOAP ones in ridiculousness. Then again.. I've never once experienced the inverse (a SOAP API that wasn't awful)... Consider context though. SOAP came about in a time when CORBA and DCOM were popular remoting strategies. Hard to fault folks thinking it was a big enough step forward :)

MindTwister 16y ago

SOAP in visual studio might be a pain, but its really not that difficult when working in PHP: http://php.net/manual/en/book.soap.php http://php.net/manual/en/book.soap.php I've implemented both servers and clients using SOAP with low to no hassles. Bad implementation != bad spec

praptak 16y ago

Not that I'm a big SOAP fan, but the author seems to be seriously confused: "For starters you have to point Visual Studio (sigh) to the service reference, at which point nine thousand (yes, that’s nine-zero-zero-zero) lines of code are generated." "Not a descriptive error, or an HTTP status code, or anything that could be used to track down the problem but a “SOAP Error.”" "Long story short, in order to inspect SOAP messages you have to write a class that implements the ICLientMessageInspector interface." These are supposed to be problems with SOAP? To me they look like a crappy implementation. The conclusion is also crappy: "In my mind SOAP’s biggest failure is what some people consider to be its biggest success – it abstracts away all notion of the underlying HTTP model and replaces it with crutches like code generation." Jeez, man - SOAP has problems, but code generation!? It's not a problem with SOAP but with the way your environment integrates with SOAP. Code generation over any protocol would create the same problems and there's nothing about SOAP that makes code gen inevitable.

koevet 16y ago

I don't like Soap for the same reasons everyone hates it. Having said that, in the Java space there are plenty of tools that turn the Soap experience into a bearable one. With CXF, for instance, is quite trivial to generate client code out of a WSDL file. The generator binds the request/response payload to Java beans so the developer doesn't have to understand the intricacies of the protocol. Debugging is also simple.

route66 16y ago

To give a slightly different spin to the discussion: does REST solve some of the problems SOAP addresses? First there was REST, now closely related to HATEOAS... I see the acronyms are coming. How to discover the meaning of data in the absence of a WSDL/RESTDL? Will we have microformats with links pointing to ontology-servers? Wat if its JSON? I wonder what REST looks like five years from now, when for instance, IBM and M$ become involved in a standardization process ...