4 ms·

Compared to SOAP, this was pretty minimalistic and a pragmatic way to talk to a server from a browser. And of course people actually used SOAP as a really convo

Compared to SOAP, this was pretty minimalistic and a pragmatic way to talk to a server from a browser. And of course people actually used SOAP as a really convoluted way to do RPC. This was the lightweight alternative. Json rpc also briefly was a thing. I had the "pleasure" of dealing with a few SOAP web services a few times. That stuff was just completely horrible and unusable. HTML5 became a thing when W3C began insisting that XHTML should be a thing, complete with namespaces and other nonsense. That was peak XML basically. Developers rejected it. Browser vendors and content creators basically stepped in and fixed HTML and CSS properly because w3c could not be bothered to step over the semantics and actually define how that stuff was supposed to behave in the real world (i.e. specifiying the semantics of their semantic HTML). Come to think about it, there was a whole bunch of things that came out of w3c that essentially was about using namespaced XML: web service architecture, RDF, semantic web, XHTML, etc. All that stuff seems to have faded away into obscurity. XML namespaces sound like a good idea until you realize that it just means endless verbosity that doesn't really serve much purpose and that really complicates things like parsing. Thankfully, people simply refused to apply that to json. Most json continues to be free of that nonsense. Same with yaml and similar formats. Works great without a lot of namespace urls.

oofbey 4y ago
It wasn’t “people” who saved JSON from this nonsense. It was Douglas Crockford, alone. I have been frequently annoyed at him for not allowing comments in JSON, but the explicit reason was that people were using json comments to encode all the metadata and crap from XML like namespaces to make fully reversible JSON/XML converters. And Crockford very much did not want JSON to be compatible with XML - he wanted it to be a simpler alternative. So good on him.
- kstrauser 4y ago
  I hadn’t heard that explanation for not having comments, but if true, I want to buy him a drink.
- kortex 4y ago
  > the explicit reason was that people were using json comments to encode all the metadata and crap from XML like namespaces to make fully reversible JSON/XML converters Oh is that why. I had heard that comments were taken out because people were using it for "parser directives" or something vague. This makes a lot more sense (although I'm sure there were all manners of hacks in the comments). Definitely a bullet dodged there.
- jillesvangurp 4y ago
  Oh many people have tried adding namespaces to json. It's just that these people and their solutions are consistently ignored by most developers. If you consider that Json came out of the javascript world where people tend to prefer to not specify a lot of types, it's perfectly obvious that they would probably not want or need any namespaces. Never was a thing in Json. And good on Douglas for keeping Json simple. The comment thing is annoying indeed. Using a good parser, you can usually configure it to not freak out over stuff like that. But sadly that is not very common. Elasticsearch is a positive exception. It will happily accept comments.
- vbezhenar 4y ago
  I don't understand why is it hard to build a JSON/XML converter? XML is represented by a DOM and DOM should be easy to convert to JSON. Actually I did just that. I made a service which uses XML for inputs and outputs and those JavaScript people kept asking me about JSON. Not sure if they were happy in the end, JSON is too verbose to my taste, but whatever. So some simple XML like <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <detail> <ns2:SendMessageFault1_SendMessageFault xmlns:ns2="http://bip.bee.kz/SyncChannel/v10/Types"> <errorCode>SCE013</errorCode> </ns2:SendMessageFault1_SendMessageFault> </detail> </soap:Fault> </soap:Body> </soap:Envelope> is represented by the following JSON monstrosity: { "name": "soap:Envelope", "attributes": [ { "name": "xmlns:soap", "value": "http://schemas.xmlsoap.org/soap/envelope/" } ], "children": [ "\n ", { "name": "soap:Body", "children": [ "\n ", { "name": "soap:Fault", "children": [ "\n ", { "name": "faultcode", "children": [ "soap:Server" ] }, "\n ", { "name": "detail", "children": [ "\n ", { "name": "ns2:SendMessageFault1_SendMessageFault", "attributes": [ { "name": "xmlns:ns2", "value": "http://bip.bee.kz/SyncChannel/v10/Types" } ], "children": [ "\n ", { "name": "errorCode", "children": [ "SCE013" ] }, "\n " ] }, "\n " ] }, "\n " ] }, "\n " ] }, "\n" ] }
  - jillesvangurp 4y ago
    Actually, that's what an automated translation would look like. A human would likely represent this as follows: { "errorCode "SCE013" } That SOAP envelope is 99% just telling you it's a SOAP envelope, which technically is completely redundant because presumably you'd be aware of the fact that you are talking to a SOAP API. And apparently they had no schema for actually telling you anything meaningful about the error. Which is why it is represented as a string with an error code. That string is the only useful bit of information in the message. Basically the SOAP equivalent of Internal Server Error. From a parsing point of view it's horrible because all those namespaces need to be resolved and the schemas need to be processed. And of course a lot of those namespace urls don't actually have servers behind them that serve those schemas. Most of those urls never resolved to anything useful at all. The servers that were supposed to host those schemas never existed. Alternatively you just ignore all that crap and pick the message apart with XPath or a regular expression. That's what I used to do when dealing with SOAP APIs. Most of those APIs were just stupendously convoluted RPC wrappers anyway from some bit of enterprise crap ware. I never could be bothered to treat those systems with the respect they demanded from me. Way faster to just sidestep all that nonsense. Send a message, pick apart what comes back to determine success / failure and move on with your life. That's why SOAP died. Because as soon as people caught up to this being the optimal way to deal with SOAP, the next logical thing was to get rid of it entirely.
- the_biot 4y ago
  Not a super fan of JSON, not least because it has no comments, but that was totally the right call on his part. We'd have a ton of semi-de-facto crap to parse out of comments by now.

oofbey 4y ago

It wasn’t “people” who saved JSON from this nonsense. It was Douglas Crockford, alone. I have been frequently annoyed at him for not allowing comments in JSON, but the explicit reason was that people were using json comments to encode all the metadata and crap from XML like namespaces to make fully reversible JSON/XML converters. And Crockford very much did not want JSON to be compatible with XML - he wanted it to be a simpler alternative. So good on him.

kstrauser 4y ago
I hadn’t heard that explanation for not having comments, but if true, I want to buy him a drink.
kortex 4y ago
> the explicit reason was that people were using json comments to encode all the metadata and crap from XML like namespaces to make fully reversible JSON/XML converters Oh is that why. I had heard that comments were taken out because people were using it for "parser directives" or something vague. This makes a lot more sense (although I'm sure there were all manners of hacks in the comments). Definitely a bullet dodged there.
jillesvangurp 4y ago
Oh many people have tried adding namespaces to json. It's just that these people and their solutions are consistently ignored by most developers. If you consider that Json came out of the javascript world where people tend to prefer to not specify a lot of types, it's perfectly obvious that they would probably not want or need any namespaces. Never was a thing in Json. And good on Douglas for keeping Json simple. The comment thing is annoying indeed. Using a good parser, you can usually configure it to not freak out over stuff like that. But sadly that is not very common. Elasticsearch is a positive exception. It will happily accept comments.
vbezhenar 4y ago
I don't understand why is it hard to build a JSON/XML converter? XML is represented by a DOM and DOM should be easy to convert to JSON. Actually I did just that. I made a service which uses XML for inputs and outputs and those JavaScript people kept asking me about JSON. Not sure if they were happy in the end, JSON is too verbose to my taste, but whatever. So some simple XML like <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <detail> <ns2:SendMessageFault1_SendMessageFault xmlns:ns2="http://bip.bee.kz/SyncChannel/v10/Types"> <errorCode>SCE013</errorCode> </ns2:SendMessageFault1_SendMessageFault> </detail> </soap:Fault> </soap:Body> </soap:Envelope> is represented by the following JSON monstrosity: { "name": "soap:Envelope", "attributes": [ { "name": "xmlns:soap", "value": "http://schemas.xmlsoap.org/soap/envelope/" } ], "children": [ "\n ", { "name": "soap:Body", "children": [ "\n ", { "name": "soap:Fault", "children": [ "\n ", { "name": "faultcode", "children": [ "soap:Server" ] }, "\n ", { "name": "detail", "children": [ "\n ", { "name": "ns2:SendMessageFault1_SendMessageFault", "attributes": [ { "name": "xmlns:ns2", "value": "http://bip.bee.kz/SyncChannel/v10/Types" } ], "children": [ "\n ", { "name": "errorCode", "children": [ "SCE013" ] }, "\n " ] }, "\n " ] }, "\n " ] }, "\n " ] }, "\n" ] }
- jillesvangurp 4y ago
  Actually, that's what an automated translation would look like. A human would likely represent this as follows: { "errorCode "SCE013" } That SOAP envelope is 99% just telling you it's a SOAP envelope, which technically is completely redundant because presumably you'd be aware of the fact that you are talking to a SOAP API. And apparently they had no schema for actually telling you anything meaningful about the error. Which is why it is represented as a string with an error code. That string is the only useful bit of information in the message. Basically the SOAP equivalent of Internal Server Error. From a parsing point of view it's horrible because all those namespaces need to be resolved and the schemas need to be processed. And of course a lot of those namespace urls don't actually have servers behind them that serve those schemas. Most of those urls never resolved to anything useful at all. The servers that were supposed to host those schemas never existed. Alternatively you just ignore all that crap and pick the message apart with XPath or a regular expression. That's what I used to do when dealing with SOAP APIs. Most of those APIs were just stupendously convoluted RPC wrappers anyway from some bit of enterprise crap ware. I never could be bothered to treat those systems with the respect they demanded from me. Way faster to just sidestep all that nonsense. Send a message, pick apart what comes back to determine success / failure and move on with your life. That's why SOAP died. Because as soon as people caught up to this being the optimal way to deal with SOAP, the next logical thing was to get rid of it entirely.
the_biot 4y ago
Not a super fan of JSON, not least because it has no comments, but that was totally the right call on his part. We'd have a ton of semi-de-facto crap to parse out of comments by now.