Ask HN: JSON vs. XML?
Do you prefer JSON or XML? Why?
JSON's data model lines up much better with common data structures in programming languages, while the often-maligned child-element vs. attribute distinction in XML makes a lot of sense to me to distinguish between globally relevant metadata (attributes) vs. data that can stand on its own (elements).
When HTTP APIs started winning out at the expense of SOAP or XML-RPC APIs, JSON became preferred because there was no schema to validate and a client could just parse out the fields they were interested in and ignore the rest.
Nowadays, more and more deployments add a JSON Schema, officially discouraging that practice and negating one unique differentiator it had versus XML. They're both text-based formats you have to parse, and for internal, non-outward-facing purposes I'd rather use a binary serialization format instead for compactness and because I control both endpoints.
My other preferences are, for outward-facing purposes (like a HTTP API return payload), a custom mediatype based on JSON or XML (in that order, because JSON has more community goodwill); for configuration files, neither because the're both awful to type in a line-oriented setting; and for protocol or file-format type things that could conceivably stand on their own and be called a 'document' (like a self-contained file at rest), XML or binary because they allow strongly typed, well-specified formats with less developer effort -- not JSON.
Most times you're using XML now it's to integrate with a piece of legacy software. Now that most enterprise platforms have good support for JSON, outside of a few special use cases most projects are just going to go with JSON for the convenience of it (no crazy parsers to deal with).
If you are designing a REST API, pay attention the HTTP Accept header and return whichever the client asks for.