4 ms·

I'm not convinced. JSON objects have attributes and can contain child elements. Ordering can be provided by arrays. Namespaces are also easy to create within

by csytan 17y ago

I'm not convinced. JSON objects have attributes and can contain child elements. Ordering can be provided by arrays. Namespaces are also easy to create within objects; an example would be the "type" attribute from the Freebase API. For versioning, many APIs are accessed through a different subdomain or URL (e.g. http://api.example.com/v2/ http://api.example.com/v2/). If you're feeling somewhat enterprisey, you can also wrap your response in an "envelope" object containing all the necessary details to implement your own custom protocol.

Confusion 17y ago
JSON objects have attributes and can contain child elements JSON objects only have members. These are indistinguishable from each other and there isn't a separate species of them that is obviously metadata for the object itself. Of course you can use some special naming scheme to indicate those, but if everyone whips up their own naming scheme, consuming JSON from multiple sources becomes a maintenance nightmare, especially in the absence of something like an XSD. Namespaces are also easy to create within objects; The same arguments holds here: if everyone whips up their own version of namespacing, by using some special member to indicate the namespace, interpreting JSON from different sources becomes that much more of a maintenance hell. Moreover, many users will not use namespaces, as it isn't required. XML forces you to think about the structure of your data representation. For versioning, many APIs are accessed through a different subdomain or URL The physical URL through which an API is accessed should be entirely different from the virtual URI's used for namespaces and versioning. Now I fully agree that XML and the various specs surrounding it are bloated and overengineered, but there are some sound ideas in there that a replacement should attempt to keep. JSON can be used for simple cases, but as soon as the problem gets slightly more complex, you start adding non-standardized extensions to JSON, to obtain goals that XML has foreseen. I don't believe they can replace each other: they both have their own niche.

by csytan 17y ago

Confusion 17y ago

JSON objects have attributes and can contain child elements JSON objects only have members. These are indistinguishable from each other and there isn't a separate species of them that is obviously metadata for the object itself. Of course you can use some special naming scheme to indicate those, but if everyone whips up their own naming scheme, consuming JSON from multiple sources becomes a maintenance nightmare, especially in the absence of something like an XSD. Namespaces are also easy to create within objects; The same arguments holds here: if everyone whips up their own version of namespacing, by using some special member to indicate the namespace, interpreting JSON from different sources becomes that much more of a maintenance hell. Moreover, many users will not use namespaces, as it isn't required. XML forces you to think about the structure of your data representation. For versioning, many APIs are accessed through a different subdomain or URL The physical URL through which an API is accessed should be entirely different from the virtual URI's used for namespaces and versioning. Now I fully agree that XML and the various specs surrounding it are bloated and overengineered, but there are some sound ideas in there that a replacement should attempt to keep. JSON can be used for simple cases, but as soon as the problem gets slightly more complex, you start adding non-standardized extensions to JSON, to obtain goals that XML has foreseen. I don't believe they can replace each other: they both have their own niche.