Hacker News Reader

Comment by Jleagle | Hacker News Reader

I didn't realise anyone preferred Soap, even 4 years ago.

You'll be surprised that a lot of what blogs and online communities peddle as cool or not cool doesn't reflect the actual industry and professional preferences at all.

REST is trendy because everyone sells imaginary features like self-discovery, performance and universal clients, while actually shipping random ad-hoc JSON snippets over "pretty" URLs.

REST is cool because it doesn't actually exist, so there's nothing specific to criticize about it that sticks. Any attempt at REST critique is quickly drown out by the noise of thousands of REST fans saying "but this is not REST".

I've somehow managed to not run into SOAP despite having done backend exclusively for a while. From the perspective of someone who's totally naïve to it, the technology sounds like it introduces more friction to the developer than the common JSON over HTTP approach. I'd appreciate someone who favours SOAP explaining what the advantages are, I'm genuinely curious because I've never worked with it first hand.

One advantage is that there's a schema describing service that can be used to automatically generate the client code. However, getting data in and out of the auto-generated objects doesn't seem any easier than getting it in and out of JSON, so I'm not sure that's much of an advantage.

Recently I ran into an issue where the SOAP client library I was using escaped values like you normally would in XML: <xml>1 < 2 &amp cetera</xml> ... but the SOAP server required CDATA syntax, like this: <xml><![CDATA[1 < 2 & cetera]]></xml>, so the schema didn't help much there either.

Oof, that last part sounds like a faff to deal with!

We had this problem with JSON in the first few years. Various ad-hoc JSON parsers that are not in fact compliant parsers, but mix-in various JSON-like features in the syntax and have specific expectations about formatting.

The reason JSON got past this stage is that the JSON spec is sufficiently simple that when a popular JSON parser for every platform/language got established, people just used it.

XML on the other hand is a nightmare of complexity and it even had the occasional remote code execution vulnerabilities in some parsers (they're that complex). Which means many applications would "handroll" something that amounts to a child's interpretation of what XML is and expect that. Truly unfortunate.

I wonder if SOAP based on JSON would be more successful. Probably yes. But we didn't have it back then.

KISS

Reply on news.ycombinator.com