Not really. In C# I use a parsing library for which I just write a class and then the library automatically serializes the JSON into an instance of that class.

I can do the same thing with XML. Of course it doesn't necessarily go that smoothly with all xml, but as long as the xml is fairly simple like a JSON document would be it's totally fine. It's only when you start to use all the features of xml that don't fit neatly into a class model that it starts to get annoying. But if JSON serves your needs then simple xml does as well. I wouldn't use it because JSON works just fine but it's not as bad as people make it seem, unless people make it really bad.

▲

kccqzy 11 hours ago | parent | next [-]

That is actually a good approach that I have also used a lot: let the parsing library handle everything including the serialization and deserialization. But if you do that, why do you care that behind the scenes it is using JSON or XML or protobuf or something else?

	▲	ExoticPearTree 10 hours ago \| parent [-]
		Because at some point you have to debug stuff. And JSON is easier to read than XML to figure out where a problem might be.

▲

gf000 10 hours ago | parent | prev [-]

I would even go as far to say that XML may very well be better in some cases, - here you have a schema most of the time, so you can often catch e.g. schema evolution failures at compile time.

This is much less common/less standardized with json.

	▲	magicalhippo 10 hours ago \| parent [-]
		JSON schema exists. If you restrict yourself to a sensible subset of XML features in your XML schema, you can have a 1:1 correspondence to JSON and JSON Schema. We do that at work. Due to historical reasons we have a XSD but provide the complimentary JSON Schema to those who wish to send us JSON. The JSON is converted on the fly to XML based on the XSD so it can be ingested by our existing XML integration. Similar with return answers, response XMLs are converted on the fly based on the XSD to JSON. JSON endpoints validate against the JSON Schema, also generated from the XSD at runtime, XML against the XSD of course. We had a diverse set of XSDs but didn't have to tweak them to support JSON. We used restrictions and extensions, both simple and complex, we used min/max, enums, descriptions and examples and more, so not entirely boring XSDs. We did establish some conventions, attributes turns the child element to an object and the attributes become properies, just simple stuff like that. This way customers can hand us what they prefer generating and ingesting, and we don't have to worry about keeping two different schemas for the same endpoint in sync.