3 ms·
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 au
by ptx 5y ago
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.
- BoxOfRain 5y agoOof, that last part sounds like a faff to deal with!
- BulgarianIdiot 5y agoWe 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