Why does Retrofit advertise as "Type Safe" library?

Question

I was just going through their main page and it says,

A type-safe HTTP client for Android and Java

Why Retrofit advertises itself as being Type Safe while other libraries(many other popular ones) don't?

Before you answer...

There is an answer to this same question here. It says,

Type safety is the extent to which a programming language discourages or prevents type errors. A type error is erroneous or undesirable program behavior caused by a discrepancy between differing data types for the program's constants, variables, and methods (functions), e.g., treating an integer (int) as a floating-point number (float). This is common in statically typed languages such as Java and C

Thus Retrofit prevents errors of this type

If this is truly the answer then many libraries prevent these kinds of errors but none of them advertise as Type-Safe. Is it a marketing thing then?

I consider the above answer inadequate because the definition of Type Safety has not been taken seriously.

Anyway, there is another post with the definition of Type Safety. They give out examples:

Type safety means that the compiler will validate types while compiling, and throw an error if you try to assign the wrong type to a variable.

Some simple examples:

// Fails, Trying to put an integer in a string
String one = 1;
// Also fails.
int foo = "bar";

This also applies to method arguments, since you are passing explicit types to them:

int AddTwoNumbers(int a, int b)
{
    return a + b;
}

If I tried to call that using:

int Sum = AddTwoNumbers(5, "5");

As per the above definition, it would be the language(Java) and NOT the library that is specifically TypeSafe.

So, I ask, again, why does Retrofit advertise itself as a Type-Safe library?

Answer 1

I haven't been thinking too much about it, but from the moment I have started using Retrofit I understood this headline as type-safe on higher abstraction layer than what others are talking about here.

Usually we are taking programming language as a "target" for being or not type-safe. And I think this is not the case for Retrofit's headline type-safety ;) If we pretend that a whole HTTP call is a single programming language instruction (which could have some params and the value), then we can indeed say that Retrofit is type-safe... you have strictly defined what kind of result you are getting.. and you are getting this or nothing/error. Of course the error is on runtime, as you can't never really know what will be retrieved from the internet. Of course many other libraries can do that, not only Retrofit. Of course you can mislead type-safety of Retrofit by defining service with return value of ResponseBody type (that could accept anything). But generally, out of the box, you are getting library which will check, parse, validate HTTP calls' responses for you, convert into proper types and in case of any issue - will give you an error.

Simple analogy I have in my head right now (in terms of type-safe slogan):

• programming language has: instruction + arguments' & value's types

---

• retrofit has: http call + body & response's structures

---

Best Regards, Darek

Answer 2

Looking at the Retrofit project's cover page, it seems that the type in type safety refers to the request body and response body objects.

We have to remember that Retrofit is built over OKHttp, which can only handle RequestBody and ResponseBody objects. Retrofit prides itself on its ability to safely serialize these types into and from other types, using Converters.

The safety in type safety refers to Retrofit handling all the boilerplate code of ensuring correct type conversions while building RequestBody and parsing ResponseBody objects. Retrofit comes with several built in Converters which wrap around popular serialization libraries, such as GSon and Jackson.

TL;DR

The afformentioned type safety is Retrofit assuming the responsibility of bulding an HTTP request and parsing the HTTP response out of your DTOs.

You, the developer, may continue using your serialization library of choice as usual and need not worry your pretty little head on the subject.

Answer 3

My guess is because you can use custom classes as request Body e.g.

@GET("/token")
Call<Token> getToken(@Body Credentials credentials);

and you don't always have to create a String. Of cause the String will be created under the hood but you never have to touch it.

Answer 4

Let's first have a brief look at how you would use Retrofit to make a request and get a response. Typically you would do this:

@GET("user/images")
Call<UserImage> getUserImage();

And then have a model class like this, to hold the response:

public class UserImage  {

     @SerializedName("ImgId")
     private int userImageId;

     @SerializedName("ImgName")
     private String userImageName;

     //and so on...
}

Borrowing from your question -

A type error is erroneous or undesirable program behaviour caused by a discrepancy between differing data types for the program's constants, variables, and methods (functions), e.g., treating an integer (int) as a floating-point number (float).

I believe the reason Retrofit calls itself a type safe http client is because it will not allow you to call an API that does not return the exact response as what you defined. For example, if your API response used "ImageId" instead of "ImgId" (Referring to above example), Retrofit would not allow it. I believe this is the type safety Retrofit is referring to, i.e. type safety specific to serialization and deserialization, not just about treating int as float, etc. which makes it not just something that Java provides.

Hope this helps.

Answer 5

The reason Retrofit declares it self as Type Safe, directly links to the fact the entire implementation is reflected and annotated based. It handles all the conversions under the hood for request body and response request data. It will not allow mismatch in response types, from any server. Hence Type Safe, remember the essence of retrofit is a HTTp api for a strict contract between client and server.

Type Safety is not linked to primitive or object structures as the normative view would suggest, but rather the contruction and binding of network responses request bodies.