JSON vs XML Comparison

In today’s frontend-backend separation era, backend APIs typically provide data in JSON format, but it’s important to understand this is just one format option among many, such as XML. Not all service communications or frontend-backend interactions use JSON - some services explicitly use XML instead of JSON. Therefore, understanding the differences between these two formats is crucial for making appropriate choices based on requirements.

Definitions

Understanding a technology starts with its name and pronunciation. For detailed JSON and XML introductions, refer to Wikipedia.

JSON：JavaScript Object Notation

- Pronunciation: JAY-sawn

XML：Extensible Markup Language

	- Pronunciation: /ˌeks em ˈel/

Why isn’t XML called EML?

Curious about this, I Googled and found a related question. The relatively accurate answer is that when determining XML, committee members proposed their suggested full names and abbreviations, one of which was XML：Extensible Markup Language. Based on voting results, XML was finalized. The X represents anything, special, cool, and in the mathematical field, it represents variables, unknowns, possibilities.

No wonder naming has always been a challenge in the coding field.

JSON vs XML

In practical development, choosing a data format requires understanding the differences. Here are the key differences:

• JSON has smaller size compared to XML, with faster transmission speed and parsing speed
• JSON doesn’t support comments, while XML does
• JSON has explicit data types (string, boolean, number, object, array, null) - 6 data types, while XML has no restrictions on data types
• XML supports namespaces, while JSON does not

I personally agree with a friend’s answer on Zhihu

JSON’s existence is a typical case of 20% functionality solving 80% of requirements. Why not use XML? Because 80% of its features you don’t need, but when you do need them, you’ll understand that only XML can do it, JSON cannot.

Note: Both XML & JSON are case-sensitive.

JSON Serialization and Deserialization

Understanding JSON and XML requires understanding serialization issues, which can be tricky.

Using JSON as the data format and Java and JavaScript as languages, here are some points to watch out for - if you don’t pay attention, they can become pitfalls.

Java

1. Classes implementing the Serializable interface must provide a public no-argument constructor. If there’s no no-argument constructor, a runtime exception will be thrown: java.io.InvalidClassException

2. Objects transmitted in MVC controllers don't need to implement Serializable because controllers transmit not objects but bind objects to network packets, not involving serialization and deserialization

3. Commonly used Jackson and Gson libraries don't require target classes to implement the Serializable interface during serialization and deserialization

4. In serialized class files, you often see the serialVersionUID variable

   serialVersionUID is for controlling version compatibility. If we consider bean modifications backward compatible, we don’t change it; otherwise, we increase the value. If serialVersionUID’s value isn’t explicitly defined, Java automatically generates it based on class details. If class source code is modified and recompiled, serialVersionUID might change. The default value of serialVersionUID depends on Java compiler implementation, so for safety, manual declaration is better.

JavaScript

1. Objects after JSON.parse have undefined getter methods

   class Person {
     firstname: string;
     lastname: string;
   
     get fullname(): string {
       return this.firstname + ' ' + this.lastname;
     }
   }
   
   const p = new Person();
   p.firstname = 'alan';
   p.lastname = 'he';
   console.log(p.fullname); // alan he
   
   const p2 = JSON.parse('{"firstname":"alan","lastname":"he"}') as Person;
   console.log(p2.fullname); // undefined
   

   Deserialized objects don’t have methods defined in the class, so you need to instantiate a class object, for example:

   const userJSONObj = JSON.parse('{"firstname":"alan","lastname":"he"}');
   const p2 = new Person(userJSONObj['firstname'], userJSONObj['lastname']);
   console.log(p2.fullname); // alan he
   

References

• [Typescript method on class undefined](https://stackoverflow.com/questions/12702548/constructor-overload-in-typescript)
• Serializable and Externalizable Analysis