Most often in projects we need to make crucial decisions when there is a need to freeze upon a standard , language or simple as a standard. Let’s say we have a simple design decision to be taken such as which is a better standard for messaging in the project where we are set with the task of say transmitting an account details from the UI of a bank for account validation. In this case let’s say our decision is influenced by legacy and we have some backend that understands XML then the natural choice would be XML of course if there is free will option left to choose. This is simple and straightforward. Let’s say some folks in the team are voicing in the favor of JSON saying that it is really simple and it understand Java Script and that the handshake between the front end code using java script and the messaging structure can be better coupled , as a architect / manager or IT decision maker how would you approach this problem. Obviously the expectation is that you need to have used at least one of them or at least be able to understand the nitty gritties of both and what they entail.
Which one to choose ( XML or JSON ) ?
Let’s first get to know what is the likely usage of these standards in our application , this a good starting point as will ensure what is needed most for the scenario. It is not a good idea to have multiple standards being used across your application.
You want to have a simple messaging style format across your application.
Both XML and JSON are ideal candidates as long you keep your messaging format simple and not too verbose ( XML pitfall). Both are good simple ( if kept simple XML) , extensible , open and are interoperable as well.
You need to send across binary data or complex data across the wire.
If you need to transmit audio, video , images , chart , graphs kind of information then XML is a better choice for this as there is built in support for this . JSON is more for text and number like data which can be framed within lists and arrays. The flip side is JSON is simple and as it does not have this feature you can say that it is in a way secure for simple means of communication where hacks due to malicious exe and code cannot be embedded in the message format.
You need to send data alone in various related formats and not a whole complex document
XML is good when you have to send document style data with attributes and meaningful hierarchical data which can be defined extensively using attributes and nodes. JSON on the other hand is useful when you want to send key value , array ( nested ) based data back and forth.
You need to create a markup language or new language with semantics to make some configuration easy.
Let’s say you want to customize some configuration for your customer and make it simpler for him to enter configuration data. You can go ahead and create a language with special semantics , this is easier done in XML with supported parsing and logic added to the code along the side. At times while the definition of this is easier it is tough to write the compiler semantics for the processing engine to act on behalf of the XML. JSON would not be used here where expression needs to be evaluated for example.
You want to reduce overhead with scripting languages such as java script , python etc.
JSON is an ideal choice here as the data format already resembles the notation available in these languages and it is reduces the overhead of conversion from one format to another. XML can also be argued to be a best fit with library support from the languages and scripting platform.
Overall both have their pros and cons and based on your context you can trade off one against the other and use it for your purpose. If it is an n-tier application it would not be a surprise where there is a XML end tier talking to a JSON tier with conversion / adapter logic written in between them , this would ensure both co exist where the need for them is justified in the application. This kind of trade offs are most often done in day to day decision making where architectural decisions are impacted based on what feature necessitates the use of a technology, language, platform or scripting .
It does not make sense to go with the latest on the shelf or our team likes this feature lets use it or that is the new thing on the block. Anyways these can be dealt with when technical leadership meets maturity and is backed with good experience having dealt with such choices.