Reputation: 101
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?
Upvotes: 0
Views: 473
Reputation: 6704
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.
Upvotes: 0
Reputation: 6082
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 ...
Upvotes: 1