When using GSON, do I have to keep the same POJO at REST-WS consumer & provider end for serialization & deserialization?

Question

I am new to GSON, JSON & hence asking the question:

At the android end, I have to send a booking information to the REST WS on the server. So here is the question:

I have a BookingDTO & I use GSON to serialize it. I send it the REST WS on the server. Now do I also need the same BookingDTO at the server end for GSON deserialize it? (But that would mean tight coupling right?) Do I have to use GSON or can I use normal JSON?

What should be my approach?

score 1 · Accepted Answer · answered Mar 29 '17 at 10:28

1

You can use Json and parse that content into your objects or directly deal with JsonObject and JsonArray in your methods (server side).

if you want to use objects like BookingDTO you can either re create the classes on android project or reuse those classes from your server side, (or vice versa).

by creating a JAR file that only contains those classes (ex, export model package only) where all POJO classes are located.

using a JAR file makes you maintain a consistency between server and client code, when you add/delete a field, you don't have to change 2 classes, just change in one place and re export the JAR.

now to the tight coupling issue, i don't think there is a one here. because you are using a list of classes (and you need them in 2 or more separate locations/projects...) this is not coupling, this is reusing same code which should be a good practice.

Coupling is -for example- when Class A is a member of Class B, but it's not when you use Class A and Class B in 2 different systems/components ...

answered Mar 29 '17 at 10:28

Yazan

5,966
1
16
32

Using the same DTO for different environments may cause coupling issues. Let's say, if the given DTO is purely Gson-based at the client side (say, Android), it may be not purely Gson-based being stuffed with, for instance, `javax.validation` stuff at the back end (say, Spring Web) to make annotations like `@Valid` work. – Lyubomyr Shaydariv Mar 29 '17 at 10:37
@LyubomyrShaydariv if i understand your note correct, yes there will be coupling but not between same DTOs it's between DTOs and validation (?) as in ur example, it's generally an opinion, even if a DTO has another DTO as member or List then the coupling already exist, but reusing same class files in 2 components or systems is not coupling , right? unless i am misunderstanding OP question in first place ?! – Yazan Mar 29 '17 at 10:57
No, I guess you got the OP question correct, and I'm fully with you on your answer regarding code reuse: this is a perfect case for code reuse for the same DTO class. Unless the OP is going to enhance the DTO by adding extra annotations (for example, Java Validation annotations like `@Valid`, `@NotNull` etc) that are relevant to the back end only. Or vice versa: Android-related annotations are hard to make some sense at the back end (if such a DTO could be compiled without adding too specific Android stuff, though). – Lyubomyr Shaydariv Mar 29 '17 at 11:04
I just wanted to note that it's usually hard to reuse even simple data bags classes like what DTOs are in too different systems if such classes would be enhanced in the future, and it would lead to splitting the DTO class into client-specific and server-specific implementations, unfortunately. – Lyubomyr Shaydariv Mar 29 '17 at 11:08
@LyubomyrShaydariv 100% agree, i't's all about it -reusing- and when it comes to real case you simply can't, another example is using an ORM either on Android or on server side, you can't simply they have different annotations, and some ORM forces you to `extend` a class in each Model or DTO, so you get stuck in doing a non-orm sol, or just duplicate every single class you are going to use :( – Yazan Mar 29 '17 at 11:21
1

@Yazan & LyubomyrShaydariv : Thank you for the discussion. I also agree with this reuse but I should have phrased the question better. In comparison to JSON where I am sending name value pares doesnt irrespective of the order, I will get them back in the same format. But if I am using DTO jars I will have to recompile the Android app for just 1 jar update - as Gson needs exact same POJO at both the ends to make to ser/dser. Hence I had asked about coupling. – Arijit Datta Mar 29 '17 at 17:03

score 0 · Answer 2 · edited May 23 '17 at 11:54

do I also need the same BookingDTO at the server end for GSON deserialize it?

Simply put, yes, you'll have to prepare a POJO in order to receive the request. So, for that to happen, JSON deserializer will try to parse the properties off JSON request and map that to a POJO of server.

With Spring, we do stuffs like the following. This is a creating a controller of POST request type expecting to habe a param of BookingDTO type. We use Jackson library for JSON serialize and deserialize.

    @RequestMapping(value = {"/update"}, method = RequestMethod.POST)
    @ResponseBody
    public void update(@RequestBody BookingDTO bookingDTO) throws FamsException {

        // Do what you intend to do with this bookingDTO object sent from client side(Android)
    }

As it stands, if your JSON property name matches with the property name and type of BookingDTO then it can map those and you'll get BookingDTO bookingDTO object with all the matched properties.

Be sure not to send JSON request with property that isn't in the BookingDTO POJO. Otherwise, server will throw a 400 BAD REQUEST error.

Note that, you can also send Map as parameter. This won't require a matching POJO at server side. You can construct a different object by getting the data out of Map the way you like.

Hope you get the idea.

When using GSON, do I have to keep the same POJO at REST-WS consumer & provider end for serialization & deserialization?

2 Answers2