Live data from Hacker News

SOAP: The 'S' stands for simple (not really)

harmful.cat-v.org

71–80 of 92 posts

Re: SOAP: The 'S' stands for simple (not really)

#71

Earlier quoted context omitted.

I've got the same question. But I've written them in both Java and C#. I worked on a project recently where we had a team of Java guys who worked on a SOAP implementation for a month. They could not get it to work in any way, shape or form. It was handed to me, and three of us did it a half an hour. All custom SOAP, still worked. I just don't comprehend why this seems so hard to people on Hacker News. SOAP is just an…

> SOAP is just another protocol and as messy as any other. I think that's where you and most of the other people on the thread are losing it. SOAP is way messier than just good old REST. (disclaimer: I've never been forced to actually use SOAP.)

I have had to do both: SOAP is WAY more messy.

Re: SOAP: The 'S' stands for simple (not really)

#73
post #11

Must be ~5 years since I last used SOAP. Needless to say I hated the stuff. Complex to build, complex to use (interoperability between different stacks - java/.net/... - was like 'cross your fingers and hope for the best'), complex to debug and walk through tcpdump network packets. It's complex in every way but the name. Of course, since that times I've alway advised against web services and so far I've succeeded in…

Seriously? I'm actually surprised that anyone would find SOAP complex. I see it as incredibly simplistic to implement. Are you really saying you avoid web services because you don't understand SOAP? I've done them in both .NET and Java many times.

It's almost as if the vendors of such awesome technology as the .Net stack and the wonderful world of Java app servers was trying to get you to buy some brain-dead tools to manage what should be as simple http get/post

The only useful thing SOAP has done for the entire development community is to give lead developers or tech managers making hiring decisions a huge red-flag. As soon as anyone mentions SOAP with enthusiasm (instead of the disgust it deserves), you know it's 'no-hire'

Re: SOAP: The 'S' stands for simple (not really)

#74

I will now share my secret SOAP API Pro Method: Step 1: Ignore all tools which supposedly make things easier (very important) Step 2: Find the web service API documentation Step 3: Ctrl-C example XML request Step 4: Ctrl-V example XML request into program, replacing appropriate parts with program variables Step 5: Parse the response. You're on your own here... Godspeed. :)

The company I work for has to digest a handful of XML and SOAP protocols. Theoretically, they all conform to spec A or B, and/or define their own subset of that spec with an XML language definition. There should be like 3 or 4 pieces of code which would handle every format they offer.

Practically: ctrl-C, ctrl-V, and call them when it doesn't work. More often than not it's either A) incorrect documentation, or B) you hit a bug (yes, this means their sample-code doesn't work. It happens frequently). A good chunk of our request-data builders are simply string manipulators, because some of the APIs we call are nitpicky about the order of XML attributes in a tag.

I laugh when people tell me XML works better "because it's a standard".

Re: SOAP: The 'S' stands for simple (not really)

#77
post #44

Earlier quoted context omitted.

Designing an API is a skill in itself, but I think rule 1 is "Don't use SOAP" JSON over REST seems to be flavour of the month FWIW.

"Flavour of the month" might be a bit harsh. It certainly is popular these days, so it's not wholly inappropriate. But it's worth noting JSON/REST is popular with, and largely because of, people who've learned the painful lessons of earlier messes like SOAP. It's not (just) a hot new thing used by new faces who've never really known any other way.

I actually didn't mean to disparage JSON over REST in any way. In fact I really like it.

I only qualified the statement as technologies change quickly (only 12 months age we would probably have been talking about XML over REST) and things will no doubt change again.

Re: SOAP: The 'S' stands for simple (not really)

#78
It's easy to rant, but hard to come up with a viable alternative, that encompasses the same scope. XML-schema and WSDL are mocked as an aside, but I dare you to provide me a REST alternative for those, as standardized as those. For all the horror stories, I have used Java to interact with a C# webservice without any pain, including WS-Adressing. The WSDL and XML-schema were a godsend compared to the earlier spec.

Like people that think you can just replace XML with JSON: you are missing stuff.

Re: SOAP: The 'S' stands for simple (not really)

#79
post #11

Must be ~5 years since I last used SOAP. Needless to say I hated the stuff. Complex to build, complex to use (interoperability between different stacks - java/.net/... - was like 'cross your fingers and hope for the best'), complex to debug and walk through tcpdump network packets. It's complex in every way but the name. Of course, since that times I've alway advised against web services and so far I've succeeded in…

Seriously? I'm actually surprised that anyone would find SOAP complex. I see it as incredibly simplistic to implement. Are you really saying you avoid web services because you don't understand SOAP? I've done them in both .NET and Java many times.

Have you had different SOAP stacks talking to each other?

The case of having identical SOAP implementations at either end (eg .NET 2.0 .NET 2.0, Java w/ Axis 1.4 Java w/ Axis 1.4) is the one scenario where SOAP works as you'd hope.

Post reply on HN