https://kotlinlang.org logo
Title
a

alex

03/29/2018, 9:18 AM
Hi, can you recommend any (maybe Kotlin based) HTTP client library? I am using OkHttp at the moment and gathered experience with Jersey... I am thinking of trying out http://hc.apache.org (Apache HttpComponents) What do you think?
p

Pierre-Luc Paour

03/29/2018, 9:19 AM
HttpClient is old and very obtuse, I wouldn't recommend it
a

alex

03/29/2018, 9:21 AM
Yes, this is what is mentioned in the URL provided... Apache HttpComponents is the successor
the URL name is missleading
It should be rather "I am thinking of trying out Apache HttpComponents "
p

Pierre-Luc Paour

03/29/2018, 9:23 AM
Same difference 🙂
a

alex

03/29/2018, 9:23 AM
just updated my initial question... you mean HttpComponents is not worth it?
p

Pierre-Luc Paour

03/29/2018, 9:27 AM
HTTP2 support is still not in a stable release for example
a

alex

03/29/2018, 9:31 AM
can you recommend anything else than OkHttp as an alternative?
p

Pierre-Luc Paour

03/29/2018, 9:38 AM
I guess it would depend on the reason you want an alternative to OkHttp.
To gain experience, the Apache stuff is probably fine
I wouldn't use it in a shipping product; too big and unwieldly (unless their design philosophy took a radical turn)
I'm also approaching this from the point of view of Android. Server-side, use-cases are different
a

alex

03/29/2018, 9:41 AM
e.g. OkHttp does not provider a serializer and instead of doing things like
Response<MyDTO> myModel = response.body();
(which is e.g. possible with Jersey) I need to to explicitly use e.g. Jackson for deserialization.
which is too much low level details in the code
also I am not doing any Android stuff...
but I also do not want a server-centric library. Or is OkHttp a bad choice when I want to e.g. run performance tests which requires a high throughput HTTP library?
c

christophsturm

03/29/2018, 10:07 AM
i recomment http4k. okhttp is a really bad library imo
with http4k you have a nice kotlin api and you can plug in any client lib that you want, i would recommend jetty-client
also check out the #http4k channel
a

alex

03/29/2018, 10:09 AM
@christophsturm thanks, look nice. Still I use Java for the backend... is the API interoperable with Java?
I've made an awful experience with Scala library & Java interop 7y ago...
c

christophsturm

03/29/2018, 10:10 AM
I think http4k is kotlin only. if you need a java library go with jetty-client
do you need the client lib in the backend?
a

alex

03/29/2018, 10:11 AM
yes, primarily for the backend
c

christophsturm

03/29/2018, 10:11 AM
ok, then i recommend jetty-client
a

alex

03/29/2018, 10:11 AM
I am not doing any Android development
do have any experience with Jersey?
I made good experience with Jersey... so in case you could compare Jersey w/ jetty-client
c

christophsturm

03/29/2018, 10:12 AM
i guess jersey is much more high level
if jersey works for you just use this. but if you want just a http client i recommend jetty-client
a

alex

03/29/2018, 11:37 AM
why shouldn't http4k work for Java as well? Isn't Kotlin 100% Java interoperable?
I've made bad experience with Scala which was "interoperable" too... but from Kotlin I express to deliver what it promises
l

Lucas Ribeiro

03/29/2018, 11:59 AM
http4k
have interoperability with Java, but was not made to support Java, so some annotations and features may work or don`t work well in java. See this issue : https://github.com/http4k/http4k/issues/77
a

alex

03/29/2018, 12:24 PM
ok, thanks.
I just checked the inner cogs of http4k... basically it offers wrappers around the major 3 HTTP clients that we mentioned in this thread: * OkHttp * HttpComponents * Jetty Client
I guess, for the the next implementation I will go with jetty-client. Unlike HttpComponents jetty-client supports HTTP2. And unlike OkHttp it is not constrained by Android, e.g. jetty-client requires Java 8, whereas OkHttp is also fine with Java 7 and hence cannot use native lambda implementations.