JSON items don’t have attributes, which sometimes makes queries outside of a specific path or across domains difficult or impossible.
“But if you take the time to design your objects correctly…”
Or they could just choose the format that already does what is needed instead of worrying about building and maintaining serialization layers to shoehorn in a functionality that they could get for free by picking the correct format in the first place.
Also why are we having this argument? XML isn’t going away, REST already beat SOAP, and JSON is harder to read. Compressed XML is only about 10% larger than compressed JSON, and we’re talking about the metadata of a layered image file so that’s like 16kb vs 15kb.
JSON items don’t have attributes, which sometimes makes queries outside of a specific path or across domains difficult or impossible.
“But if you take the time to design your objects correctly…”
Or they could just choose the format that already does what is needed instead of worrying about building and maintaining serialization layers to shoehorn in a functionality that they could get for free by picking the correct format in the first place.
Also why are we having this argument? XML isn’t going away, REST already beat SOAP, and JSON is harder to read. Compressed XML is only about 10% larger than compressed JSON, and we’re talking about the metadata of a layered image file so that’s like 16kb vs 15kb.
As explained, its not about the compressed size only. I am talking about uncompressed data that is live patched.