5 ms·

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

BoxOfRain 5y ago
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.
- 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 &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.
  - BoxOfRain 5y ago
    Oof, that last part sounds like a faff to deal with!
  - BulgarianIdiot 5y ago
    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
BulgarianIdiot 5y 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.

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 &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.
- BoxOfRain 5y ago
  Oof, that last part sounds like a faff to deal with!
- BulgarianIdiot 5y ago
  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

BulgarianIdiot 5y 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".