Shall I use POJO or JSONObject for REST calls

Question

Recently I have stumbled upon a situation where my new team is heavily using JsonObject for doing rest data interchange. Their view is while using pojo we are binding tightly with the rest service, while jsonObject gives freedom. Also it saves from unnecessary data serialisation at the same time reducing number of classes heavily.

I have some points to encounter them as:

1. Pojo gives more meaning to data and we are holding data with correct data type.
2. If we need only 2 fields of 10 fields of json, we can deserialize to 2 fields class with @JsonIgnore

I don't know exactly on the cost of deserialisation, but somehow I have a feeling it shouldn't be much difference.

Can someone help me understand which perspective is way to go ?

Please provide some pros and cons of using POJO and JSONObject.

Thanks

Answer 1

I see the following advantages in having pojos

1) Readability - You will not really know the structure of a complex json. writing a simple get will require one to know the structure of the json. Please refer to the "POJOs over JSON Objects" section of my article here -> https://medium.com/tech-tablet/programming-went-wrong-oops-38d83058885

2) Offers Type Checks - We could easily assign a Cat to a Dog and not even know about it till runtime.

3) Feels more object-oriented with Composition & encapsulation - It's easy to understand the designer's perspective with a POJO. A Car which IS-A Vehicle that HAS-A Wheel.

4) You could choose what you wanna deserialize and keep only that in memory - When deserializing the object that we have just received over the network, with a JSON Object, there is no way to choose what has to be deserialized and stored into memory. If you have an object of 1 MB size where only 200 Bytes is your payload, we will end up holding the entire 1 MB object in memory if we don't use POJOs.

5) Allows collection to be used and stream operations on them in a legible way - There is no native support for stream operations in a JsonNode. We will need to use a StreamStupport object which could be avoided.

6) Allows cross framework referencing. With a few annotations, you can choose to map specific fields to a database client - When you use an ORM framework for you database, it's easy to annotate and map entities to the database schema.

7) Naturally supports design patterns

8) Minimalizing non-native dependencies - Why do you have to use a JsonNode or equivalent that does not come by itself in native Java? Especially if it has the above disadvantages.

If you are concerned about the rituals that come with a pojo like having getters, setters etc, take a look at "Lombok". This library will help you create your pojos in a concise way and still reap the above benefits.

On the other hand if you are are dealing with a hard to change legacy API that responds with a dynamically changing response, JsonNode is a quick win candidate.