CODEWITHSUNDEEP
javajsonretrofit2
AGuyAskingQuestions
AGuyAskingQuestions

Reputation: 77

Java Retrofit2 POST JsonObject good practice?

I want to work with a REST API in my Java application. For my calls I use retrofit2. Often, I have to POST objects, that I only need once, so I'm asking myself if I really should add an additional class.

(for example UserCreate) just to create new resources (because often I receive completely different objects than I need to create the resource of the same type)

The alternative is to use com.google.gson.JsonObject for this situations. This enables me to create Json objects that don't need an additional class.

For example:

JsonObject obj = new JsonObject();
obj.addProperty("foo", "bar");
Call<Something> call = caller.createSomething(obj);

Upvotes: 3

Views: 67

Answers (2)

LppEdd
LppEdd

Reputation: 21154

This question isn't valid only for Retrofit2. I work daily with Spring and JAX-RS and sometimes I ask myself if creating all those simple (well sometimes they get pretty complex, I admit it) classes was a good idea or not.

Anyway, there isn't a universal response to that. Developers have different taste and preferences when it comes to API design, both client and server side.

However, having a Java class describing a request body or a response body format is pretty useful. If those classes respect a naming convention (such as appending *Request or *Response), if they're collected inside specific, meaningful packages, they'll make your co-workers life easier over time.

Using Java classes means making your API interfaces more robust, as the compiler will help you find problems while coding. On the other hand, by using an untyped JsonObject (or whatever object is provided by the Json library you'll use) you'll need to be more careful.

Using Java classes you can also leverage polymorphism and construction patterns. You can code by interfaces, and not by concrete objects.

Certain services which expose APIs to the outer world may also give you Jar files containing pre-compiled classes to include in your classpath.

Answering your third point, constructing a JsonObject manually using Gson and than submitting it via RequestBody doesn't incur in performance penalties. Remember that when using Java DTOs as @Body, there is a serialization process which is taken care of by Gson. It might also be that constructing JsonObjects manually is better from a performance point.

Upvotes: 1

pirho
pirho

Reputation: 12235

Often, I have to POST objects, that I only need once, so I'm asking myself if I really should add an additional class.

Your question might raise opinion based answers... But I anyway try to stress few - hopefully opinion free - points. Firstly what do you accomplish if you decide to construct JsonObject instead defining a DTO class for your data?

I mean if you had a DTO like:

@AllArgsConstructod
FooBarDTO {
    String foo;
    Integer age;
}

and then use it like:

Call<Something> call = caller.createSomething(new FooBarDTO("bar",42));

It really does not cost you too much to create that DTO class but it will give you things like:

  • type safe instantiation of DTO easily
  • if you later need to change things you do not necessarily need to hack client & server side logic (when it comes to creating JsonObject) maybe you just need to modify the DTO a bit.

So your UserCreateDTO would have stuff already parsed nicely in it. You would save the effort and maintenance of code that would do something like:

user.setAge( jsonObject.getAsInt("age") ):

but (ok, I admit this might raise opinions) a more robust way:

user.setAge(dto.getAge());

The alternative is to use com.google.gson.JsonObject for this situations. This enables me to create Json objects that don't need an additional class.

Yes but it then requires some other things when your server parses the data. You would then need to handle some details like getting the property and knowing in the parse time if it is int, string, array of somehting.

Upvotes: 1

Related Questions