6 ms·

The way to upgrade SOAP clients is to generously pour the office with gasoline and set it on fire.

by keymone 5y ago

mirekrusin 5y ago
It's a SOAP so flush down the toilet should do the trick.
- occz 5y ago
  What are your gripes with SOAP? Genuinely interested. I've used it once professionally, and while there was an initial learning curve, it seemed to have some nice properties once you got past that.
  - keymone 5y ago
    http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
    - MathMonkeyMan 5y ago
      thank you for this
    - selcuka 5y ago
      That was exactly my sentiments back in 2000s. I had to use SOAP a few times, then switched to a semi-proprietary binary protocol called Hessian [1] (and its XML based sister, Burlap [2]) and it saved my day. [1] http://hessian.caucho.com/ http://hessian.caucho.com/ [2] http://hessian.caucho.com/doc/burlap.xtp http://hessian.caucho.com/doc/burlap.xtp
    - kaba0 5y ago
      This is a ridiculous website: http://harmful.cat-v.org/software/ http://harmful.cat-v.org/software/ They should be using rocks instead of a computer with this mindset.
      - keymone 5y ago
        What does the content on the rest of the site have to do with the link I posted? This is literally ad hominem - disregarding an argument because you dislike the author.
        kaba0 5y ago
        I dislike the author based on his/her writings. Why would it be ad hominem (which is not even that)? Also, the link I posted is even about the same topic, not unrelated - so a logical flow in that one (and it has plenty) will easily apply just as well to an elaboration of one of the listed contenders on this page.
        keymone 5y ago
        dismissing the argument based on your feelings about the author is literally ad hominem.
  - dtech 5y ago
    Just like with XML, it's suffers from being about 300x more complicated than is proper for what is does
    - acomjean 5y ago
      I really like Java the language but I feel everything involved in working in Java is 300x more complex than it needs to be. (Even with a IDE) Just getting code updates on our old java websites makes me realize why all the new stuff is arguably slower php and python..
      - native_samples 5y ago
        SOAP isn't a Java tech.
  - Spivak 5y ago
    SOAP is fine if you're talking to yourself or otherwise confined to a single dialect. But that's not saying much since that's true of any data format. SOAP falls down when trying to get systems all developed by n different companies all talking to one another which was/is the whole point of the stupid thing.
    - codr7 5y ago
      Word. As long as you're running the same code on both ends it sort of works. It's still over engineered to the moon and back, and a major pita to deal with, but at least the damn thing works. Anything beyond that fails in spectacular ways. It will not be missed.
      - TedDoesntTalk 5y ago
        The people responsible for inflicting SOAP upon us should suffer.
    - kaba0 5y ago
      But SOAP endpoints can be autogenerated (as opposed to REST), which basically makes this much less of an issue.
    - occz 5y ago
      Was there a lot of competing standards in SOAP, leading to incompatibility between libraries? That would indeed seem to defeat the point, if true.
  - matchagaucho 5y ago
    If you use the "Simple Object" abstraction, it's just fine. Delving under the XML hood can be painful.
  - ahepp 5y ago
    My experience: It's very easy to overengineer. Both the SOAP WS-* extensions, and the underlying XML. The tooling and ecosystem suck. I found it a lot more difficult to use clients like soapUI as opposed to just banging on a REST API with curl. The libraries are mostly java, with at least one c/c++ implementation. I had a lot of trouble getting different libraries to work together. And that's literally the entire point of SOAP. It's supposed to be the enterprise grade interoperability (of course, a huge oxymoron) compared to REST.
  - chaostheory 5y ago
    SOAP and its XML schema and result is 100x more complicated than JSON. The problems outweighed the benefits. I spent a few years working on SOAP for a telecom. Not pleasant.
    - occz 5y ago
      >SOAP and its XML schema and result is 100x more complicated than JSON. The problems outweighed the benefits. Please mention a few of these problems, I'm curious to hear. The problem I see with REST/JSON-APIs is that they lack features that have to be tacked on after, creating an endless bikeshedding nightmare and instead of having one well-thought out solution, you get three or four solutions sloppily hacked together. Schemas are a prime example, actually: SOAP appears to come with them out of the box, while REST/JSON-APIs either lack them (just about as bad as not having any type system in your language, i.e. really bad) or tack them on after the fact with something like OpenAPI, which is honestly not great as far as schema languages go. Again, I say this as someone who has professionally used SOAP only once, and very briefly at that. Not advocating that we should re-adopt SOAP - I think that ship has sailed since long ago - but I really want to understand its opponents opposition to the positive qualities it appears to have.
      - chaostheory 5y ago
        I used it for about 3-4 years at a major telecom and a large retailer a while back. > Schemas are a prime example, actually: SOAP appears to come with them out of the box, while REST/JSON-APIs either lack them (just about as bad as not having any type system in your language) The problem with SOAP is that it seemed to be designed by multiple committees with different agendas. From my imperfect memory, it's not just different versions of SOAP you have to contend with, but also different variants of schema flavors. Consequently, different languages and even libraries would have implementations that might support x but not y schema feature. It was an annoying compatibility nightmare, where you needed an additional complicated tool to verify it all. Yes, JSON/REST have their own issues, but it's nothing that good documentation can't solve, and it's supported across most if not all major programming languages. Simplicity is often very underrated.
  - ralphc 5y ago
    This is from 10+ years ago, but my biggest gripe with SOAP was that if you didn't have the exact same library on both ends then you have problems. Apache Axis vs CSF vs soap-ws, and that's just Java. Java to .NET was almost impossible to pass around.
    - occz 5y ago
      That would indeed be a huge downside - the point of a specifiation would be to have interoperability be entirely seamless. If SOAP failed on that account, then it deserves its fate.
- pabl0rg 5y ago
  Publishing some flavor of SOAP services seems to be easy and common in companies that live in the Microsoft ecosystem. I’m no fan of that, but unfortunately we are forced to use some such SOAP services.

The way to upgrade SOAP clients is to generously pour the office with gasoline and set it on fire.

mirekrusin 5y ago

It's a SOAP so flush down the toilet should do the trick.

occz 5y ago
What are your gripes with SOAP? Genuinely interested. I've used it once professionally, and while there was an initial learning curve, it seemed to have some nice properties once you got past that.
- keymone 5y ago
  http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
  - MathMonkeyMan 5y ago
    thank you for this
  - selcuka 5y ago
    That was exactly my sentiments back in 2000s. I had to use SOAP a few times, then switched to a semi-proprietary binary protocol called Hessian [1] (and its XML based sister, Burlap [2]) and it saved my day. [1] http://hessian.caucho.com/ http://hessian.caucho.com/ [2] http://hessian.caucho.com/doc/burlap.xtp http://hessian.caucho.com/doc/burlap.xtp
  - kaba0 5y ago
    This is a ridiculous website: http://harmful.cat-v.org/software/ http://harmful.cat-v.org/software/ They should be using rocks instead of a computer with this mindset.
    - keymone 5y ago
      What does the content on the rest of the site have to do with the link I posted? This is literally ad hominem - disregarding an argument because you dislike the author.
      - kaba0 5y ago
        I dislike the author based on his/her writings. Why would it be ad hominem (which is not even that)? Also, the link I posted is even about the same topic, not unrelated - so a logical flow in that one (and it has plenty) will easily apply just as well to an elaboration of one of the listed contenders on this page.
        keymone 5y ago
        dismissing the argument based on your feelings about the author is literally ad hominem.
- dtech 5y ago
  Just like with XML, it's suffers from being about 300x more complicated than is proper for what is does
  - acomjean 5y ago
    I really like Java the language but I feel everything involved in working in Java is 300x more complex than it needs to be. (Even with a IDE) Just getting code updates on our old java websites makes me realize why all the new stuff is arguably slower php and python..
    - native_samples 5y ago
      SOAP isn't a Java tech.
- Spivak 5y ago
  SOAP is fine if you're talking to yourself or otherwise confined to a single dialect. But that's not saying much since that's true of any data format. SOAP falls down when trying to get systems all developed by n different companies all talking to one another which was/is the whole point of the stupid thing.
  - codr7 5y ago
    Word. As long as you're running the same code on both ends it sort of works. It's still over engineered to the moon and back, and a major pita to deal with, but at least the damn thing works. Anything beyond that fails in spectacular ways. It will not be missed.
    - TedDoesntTalk 5y ago
      The people responsible for inflicting SOAP upon us should suffer.
  - kaba0 5y ago
    But SOAP endpoints can be autogenerated (as opposed to REST), which basically makes this much less of an issue.
  - occz 5y ago
    Was there a lot of competing standards in SOAP, leading to incompatibility between libraries? That would indeed seem to defeat the point, if true.
- matchagaucho 5y ago
  If you use the "Simple Object" abstraction, it's just fine. Delving under the XML hood can be painful.
- ahepp 5y ago
  My experience: It's very easy to overengineer. Both the SOAP WS-* extensions, and the underlying XML. The tooling and ecosystem suck. I found it a lot more difficult to use clients like soapUI as opposed to just banging on a REST API with curl. The libraries are mostly java, with at least one c/c++ implementation. I had a lot of trouble getting different libraries to work together. And that's literally the entire point of SOAP. It's supposed to be the enterprise grade interoperability (of course, a huge oxymoron) compared to REST.
- chaostheory 5y ago
  SOAP and its XML schema and result is 100x more complicated than JSON. The problems outweighed the benefits. I spent a few years working on SOAP for a telecom. Not pleasant.
  - occz 5y ago
    >SOAP and its XML schema and result is 100x more complicated than JSON. The problems outweighed the benefits. Please mention a few of these problems, I'm curious to hear. The problem I see with REST/JSON-APIs is that they lack features that have to be tacked on after, creating an endless bikeshedding nightmare and instead of having one well-thought out solution, you get three or four solutions sloppily hacked together. Schemas are a prime example, actually: SOAP appears to come with them out of the box, while REST/JSON-APIs either lack them (just about as bad as not having any type system in your language, i.e. really bad) or tack them on after the fact with something like OpenAPI, which is honestly not great as far as schema languages go. Again, I say this as someone who has professionally used SOAP only once, and very briefly at that. Not advocating that we should re-adopt SOAP - I think that ship has sailed since long ago - but I really want to understand its opponents opposition to the positive qualities it appears to have.
    - chaostheory 5y ago
      I used it for about 3-4 years at a major telecom and a large retailer a while back. > Schemas are a prime example, actually: SOAP appears to come with them out of the box, while REST/JSON-APIs either lack them (just about as bad as not having any type system in your language) The problem with SOAP is that it seemed to be designed by multiple committees with different agendas. From my imperfect memory, it's not just different versions of SOAP you have to contend with, but also different variants of schema flavors. Consequently, different languages and even libraries would have implementations that might support x but not y schema feature. It was an annoying compatibility nightmare, where you needed an additional complicated tool to verify it all. Yes, JSON/REST have their own issues, but it's nothing that good documentation can't solve, and it's supported across most if not all major programming languages. Simplicity is often very underrated.
- ralphc 5y ago
  This is from 10+ years ago, but my biggest gripe with SOAP was that if you didn't have the exact same library on both ends then you have problems. Apache Axis vs CSF vs soap-ws, and that's just Java. Java to .NET was almost impossible to pass around.
  - occz 5y ago
    That would indeed be a huge downside - the point of a specifiation would be to have interoperability be entirely seamless. If SOAP failed on that account, then it deserves its fate.
pabl0rg 5y ago
Publishing some flavor of SOAP services seems to be easy and common in companies that live in the Microsoft ecosystem. I’m no fan of that, but unfortunately we are forced to use some such SOAP services.