Design Considerations: When Should We Use JSON instead of XML as Data-interchange Format?
JSON partially support references using JSONPath, JPath, JSPON and json:select().
XML is a markup language and is a textual data format. Any character defined by Unicode may appear within the content of an XML document. XML document’s logical structure can be validated against XML schema. XML Schema definition is more powerful than its predecessor DTD and uses rich data typing system. XML Namespaces enable the same document to contain XML elements and attributes taken from different vocabularies, without any naming collisions occurring.
XML Signature defines syntax and processing rules for creating digital signatures on XML content. XML Encryption defines syntax and processing rules for encrypting XML content. XML supports references using XPath and XPointer. There are many programming interfaces exist such as SAX, DOM and XML Data Binding such as JAXB.
JSON is extensively used with Ajax and one example is by using XMLHttpRequest object to request data in JSON format from a server.
If you are developing a public web service and an open API, that are to be consumed by any programmers, then first choice would be JSON format. But if you are looking for security(signature, encryption etc) , transformations, complex validations, namespaces etc (As you see in B2B applications) XML is the better choice. Data standardization is much more mature with XML than JSON.
JSON would be best to use when performance and bandwidth usage is more important than structured and flexible data. For example preference should be given to JSON where the size of the message being sent is of critical importance to the end-user, such as mobile applications consuming data from servers.
As we know, XML payload can be secured in many ways, it can be signed and encrypted. We have XML-Encryption that allows the XML document to be encrypted and also describe the kind of encryption cipher used. But in case if JSON, as its specification doesn’t include encryption, you need to consider security by other means. Encrypting individual JSON elements or the whole JSON objects will be a problem for the client, since it has to deal with the decryption process based on server encryption parameters. JSON over HTTPS is the default possibility in this case.
But if the client doesn’t have a native JSON library and the server response has to be validated against standards (read schema), then XML is the right choice.
Here the freedom has to be given to the client to use appropriate MIME type in the request and the service has to provide response in that format. The key point here is that if the web service is public it should support both JSON/JSONp, and XML.