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.
back
1 comments
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 & 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.
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
Oof, that last part sounds like a faff to deal with!