Support Response<T> return type serialization in APIServices

[Aditya94A]

I use Response wrapped response structure everywhere in my services (for error handling) so it looks like:

interface Service {
  @GET("string")
  suspend fun getAll(): Response<List<String>>

  @GET("string/{id}")
  suspend fun getSingle(@Path("id") id: Long): Response<String>
}

And then in the ktor-retrofit service implementation, I then return a

return Response.success(myResponseObj)

But for some reason, my responses are not transmitted if implemented this way, here's a snippet of the response when hitting a ktor-retrofit implemented endpoint (logged via HttpLoggingInterceptor):

Vary: Origin
Content-Type: application/json; charset=UTF-8
Connection: keep-alive
transfer-encoding: chunked

{}
<-- END HTTP (2-byte body)

Notice the empty {}

The service is installed as:

  routing {
        route("/") {
            authenticate(AuthLabel) {
                retrofitService(service = MyService)
            }

[bnorm]

So I've got this coded up and working but I'm a little hesitant to support this. retrofit2.Response on the server side seems like a leak of dependencies. Right now, if the Retrofit interface is in a separate, common module, the Retrofit dependency only needs to be present at runtime. Using Response for the interface implementation forces Retrofit to be present at compile time as well.

Is Response being used in the interface a requirement from the client side? Is there a reason to avoid HttpException? I'm just trying to better understand your use case before releasing support for this.

[Aditya94A]

Is Response being used in the interface a requirement from the client side?

Yes, actually.

Here's an example method of my user API service interface:

    @GET(V1_USER)
    suspend fun getUser(): Response<UserResponse>

So, in order to use the latest coroutine support with retrofit (along with wrapping API calls in live data on Android for good measure) using Response is pretty much the only solution. Mere HttpExceptions don't allow as much detailed handling of errors (in situations where the errors cannot just be represented by HTTP status codes). That leaves RxJava Observable<T> or raw data type handling, both of which are (IMO) worse solutions than good old Response<T>

Hence, if I can implement the same user api service, as is, on the backend using ktor-retrofit, that pretty much saves me an entire file of duplicated API endpoint paths and routing to specific methods (the usual ktor way, except without ktor-retrofit's explicit type safety, again a worse solution)

I'm wondering how common of a situation it would be where retrofit would be used at runtime but not compile time. If ktor-retrofit service() makes use of a Service in a common module, isn't it already present at compile time? (Unless someone's using reflection to load Retrofit services, which is a really bad idea for so many reasons)

Worst case, the Response handling could be released as an add-on dependency perhaps? (Kinda like how you can add a converter factory to retrofit)

Also, retrofit-2.6.2.jar is 124 Kb (before minification), not really a big deal when we're talking about server deployment.

[bnorm]

Okay, thanks for the explanation. I'll hopefully have a new release out soon.

[bnorm]

Fixed by 5d85a44 and available in latest 0.1.2 version.