Kotlin http client. Making kohttp 0.11.0

This is the first post in series observing the latest changes in kohttp and the reasons behind.

kohttp is a kotlin DSL http client. If is fully based on kotlin embedded DSL features, as a next level of API experience, and does not perform any code generation or precompile instrumentation. As for version 0.11.0 it is based on OkHttp library, multiplying it’s features by fluency of DSL syntax.

⭐⭐⭐ https://github.com/rybalkinsd/kohttp

Logging

An ability to have a proper logging is a root for quick troubleshooting in your application. Working with http client it’s really important to understand how you run request, to make sure everything is as expected: all headers are set, data is in correct formatting, etc. Thinking of it kohttp introduces first-class support for logging.

As for now you can get all the logging features simply enhancing your client.

And here is a log you will see.

Lots of problems could be solved having proper logs, however, time to time we need to reproduce server side problem. To deal with this case kohttp introduces CurlLoggingInterceptor. By simply adding it to your interceptors { } you will get a cURL command to reproduce your http call.

Modularazation

Pay Only For What You Use

There is a significant difference between applications and libraries in terms of dependencies. Integrating a library you’re also relying on it’s dependencies taking responsibility for versions conflicts. It’s getting critical if we’re talking about serialization or transport libraries, where compatibility bugs could be deeply hidden. Last, but not the least, we don’t want our users apk to increase in size more than it has to.

Let’s have a look at kohttp:0.10.0 runtime classpath tree:

A big part of dependencies are related to Jackson. And we realized that, classpath is redundant to majority of our users due to two reasons:

  • only 35%* of kohttp users also use Jackson in their builds
  • kohttp.yaml configuration feature was rarely used, < 5%*

To minimize end users’ footprint, we split library into

  1. kohttp — core DSL features including async
  2. kohttp-jackson — Jackson integration which allows to treat response body as JSON
  3. kohttp-test — integration tests

As a result the core artifact

will only add following to your build:

As you can see kotlin-reflect is gone, however, it’s a part of kohttp-jackson at the moment.

Developer Experience

Daily work with kotlin forms a notion of how different code patterns and methods should work. DSL is all about DevX. As a result kohttp needs to follow the notion.

Have a look at String.toInt and String.toIntOrNull. Even without checking sources you have some expectations about what would be the return type and possible exceptions of this two extension functions.

kohttp followed this pattern and introduced Response.toJson and Response.toJsonOrNull with the corresponding behaviour.

It’s also important to deserialize Response to an object of specific type. Response.toType is exactly the thing you’ll need for this.

Kotlin, JVM, Serverless, Java, Spring. Kotlin http DSL client https://github.com/rybalkinsd/kohttp

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store