Use JSON objects or POJOs in back end service?

Question

I'm building a back end service for mobile clients.

The requirement is that the mobile clients will pass me a token, I'll use that token to talk to other systems (behind the company firewall) in my company, and return to the user some information.

Here's a typical scenario:

A mobile client asks for some customer data and makes a call with the customers token. I use the token against the customer database system and get back the customer details. I then return the data (removing some fields that are not relevent )to the mobile client.

All data between systems (me, mobile client, customer database) use JSon.

The question is whether I should work with JSon objects throught my code or try and use POJOs?

Right now, I only need to remove some fields from the customer database before returning to the client.

The future may require more involved transformations but I can't be sure that will happen or the nature of the transformations.

Thanks

Answer 1

It's usually a good idea to separate the serialization method (JSON) from your business logic so that if in the future you decide to use some other type of serialization, you can do so without affecting the business logic.

Jackson is probably the most popular open-source library for JSON serialization/deserialization in Java.

In the situation where some amount of transformation is needed between the data received from your customer database and what you actually return to the caller, I usually create a separate DTO (data-transfer object) class that contains only the fields to be serialized.

On the other hand, if you always need to remove the same fields from the customer data before transmittal and don't mind putting serialization-specific annotations on your POJOs, you can use Jackson's @JsonIgnore (or similar) on those fields and skip the DTO.

Answer 2

I'd go for the simplest and easiest solution which will cover your current requirement.

As you mentioned all you need is to remove couple of fields, json manipulation is enough and it's very simple.

In future, as you believe if it comes to more complex transformations (which are not easy to do with json manipulation) you can easily add DTOs in middle and do the transformations. Since you are getting json and sending back json adding DTOs won't affect any of the external systems.

Answer 3

Its a classic tradeoff Performance + ease of use vs. scalability and flexability.

POJOs are highly perfomant and very easy to use in a Java program. BUT they are restricted to a single VM. You cannot pass a POJO to another VM or another server or another process not implemented in Java. To pass the POJO to a Java program in another VM you need to serialize the POJO and de-serialize it at the receiving process. The default Java serialize methods have historically been very dependent on the version of Java used.

JSON formatted messages can be passed between processes, between servers, and can be easily read by Java programs but also Javascript, php, python C, C++ etc. etc.

Other benefits of using a JSON (or XML :-) ) include ease of debugging ( you can just read the message ) and ease of testing (its trivial to create store and copy JSON messages for use in a testing framework).

Answer 4

I'm in agreement on simplest approach is generally the best and for me JSON manipulation win out hands down in this situation.

The important bit of the question is '(removing some fields that are not relevant ) to the mobile client'

So from what I understand there is more than one mobile client variant and for each different json fields are selected from the source customer data json.

Using the DTO approach, I would first have to marshall the source customer data JSON to a DTO, then if I had 4 mobile clients then I would need 4 DTO's and multiple method for setting the attributes on each Type of DTO.

Using the JSONObject approach, I would have something like:

JSONObject sourceCustomerData = JSONObject.fromObject(httpResponseInputStream)

and would pass the sourceCustomerData to a method to return the JSON suitable to individual mobile client something like:

JSONObject customerDataClientX = getRequiredJson(requiredJsonFeildsForMobileClientA, sourceCustomerData) 

where requiredJsonFeildsForMobileClientA is list of required JSON fields. Therefore for each mobile client a different list of required JSON fields can be passed in.

DTO PROS - Straight forward and verbose code POJO's. - Suitable for more complex transformations. - Easily testable.

DTO CONS - DTO's are models held in code, they cannot changed without manipulating code. - More code as DTO and there population code are directly related to the number of mobile client variants.

JSONObject PROS
- Straight forward code. - Easily testable, it's a function on external factors. - Less code as one shoe fits all, not directly related to the number of mobile client variants
- There is no model held in code, the list of JSON fields for each mobile client can be held in configuration externally.

JSONObject CONS
- Not suitable for more complex transformations. - JSONObject requires navigation JSON model, not so nice to ready or write.

In future, as more complex transformations are required we can add then in and even consider moving to a DTO’s based model if it makes the task easier.