Home » Architecture » Architecture Tips » Design Considerations: When Should We Use JSON instead of XML as Data-interchange Format?

10 Flares Twitter 1 Facebook 0 Google+ 5 LinkedIn 4 Email -- Filament.io 10 Flares ×

As we know, JSON (JavaScript Object Notation) is a lightweight and text based data-interchange format that is used frequently replacing XML. The question is, when should we consider JSON instead of XML as the data interchange format?

Few Points: JSON and XML

JavaScript Object Notation (JSON) is a text format for the serialization of structured data. JSON can represent four primitive types (String, Number, Boolean and NULL) and represent two structured types Object ( An unordered collection of zero or more name/value pairs. In an object name is a string and value can be string, number, boolean, null, object, or array) and array( An array is an ordered sequence of zero or more values).
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.

JavaScript Runtime and JSON

Usually the JSON formatted text is syntactically JavaScript valid. Even though the built-in JavaScript eval() function can be used to parse JASON data, it is not recommended because of security concerns. The fifth edition of ECMAScript standard included a much safer JSON.parse() and JSON.stringify() functions . This is supported by majority of the browsers. JASON being native on the browsers with JavaScript runtime, interpretation of JASON data on the web pages will be much faster than XML.
JSON is extensively used with Ajax and one example is by using XMLHttpRequest object to request data in JSON format from a server.

Performance & bandwidth Considerations

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.

Security and Standards

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.
If you are transferring extremely sensitive data between client and endpoint across multiple intermediaries, then it is better to consider XML. JSON is ideal for browser (has in-built JavaScript interpreter) to server interaction, over HTTPs or HTTP, where, there is no intermediaries or you trust the intermediaries along the SSL pair segment paths.

Scalable Web APIs: Let the Client or Consumer Decide the Data-Interchange Format

When designing public facing web services, one has to ensure that the service should not force the consumer to choose between JSON and XML. A well designed web service should allow client service to get the data in the format best suited to its need. For example if the client uses the JavaScript runtime exclusively and does some data processing the then JSON as the serialization format is a better choice. This is because the JSON data is already in JavaScript Object syntax and the runtime de-serialization process is highly optimized.
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.

JSON will reduce the payload size and saves a lot in parsing compared to XML. JSON will be a strong candidate when JavaScript plays an important role in design. It is also a better choice when performance and bandwidth is key decision makers. When security, complex data validation, meta-data and standardization are important, then XML gain more importance.
JSON has the strength that it is compact, small and with a less verbose structure and is using it is a frugal approach. Its more suitable when direct communication with JavaScript in a web environment is required.XML scores as an extensible way to represent data that can easily be read by many different systems and secured using many methods.


10 Flares Twitter 1 Facebook 0 Google+ 5 LinkedIn 4 Email -- Filament.io 10 Flares ×

About Binu George

Leave a Reply

Your email address will not be published. Required fields are marked *

Paged comment generated by AJAX Comment Page

Google+ Plus Follow on Twitter Like On Facebook Linked Follow

Popular post

JAX-WS Web Services and Clients Java JAX-WS Tutorial: Develop Web Services and Clients (Consumers) Using JAX-WS
jax-ws usernametoken example JAX-WS and Secure Java Web Services using UsernameToken : WS-Security with Metro and WSIT
How to Fix : java.security.cert.CertificateException: No name matching localhost found
JAX-WS exception fault handling example JAX-WS Exceptions and Faults: Annotation, Exception and Fault Handling Examples
SOAP Binding: Difference between Document and RPC Style Web Services

Subscribe to Enterprise Java newsletter
Get Enterprise Java Newsletter

Enter your email and stay on top of things,