> OkHttp 5 - Breaking: Drop support for Kotlin ...

# squarelibraries

[ursus]

OkHttp 5 - Breaking: Drop support for Kotlin Multiplatform.

Oh crap, really?

[ursus]

I'm comfortable to okhttp being just a JVM networking engine, i.e. what URLSession is on ios and have a "retrofit/ktor" sit ontop and provide a hig level api, however

what sort of bothers me about this is that I have a bunch of logic in `Interceptor`s, whole auth layers etc.

Does this mean I should push this sort of middleware to the higher level layer and roll my own middleware api? I don't like having auth done multiple times 😕.

[ephemient]

it never made it out of alpha

[ephemient]

so no change for okhttp 4.x or earlier consumers

[ursus]

yea I'm aware, I was just counting on this to share my auth layer/interceptors

[ephemient]

ah. then it's the same as the present situation. you can try sharing across platforms with logic in ktor

[ursus]

hm, ktor wraps okhttps auth?

[ursus]

I thought it was out of scope, same as retrofit

[ephemient]

ktor can use okhttp as a client engine

[ursus]

right but Authenticator is a okhttp type, how to bring that to multuplatform, does ktor have the equivalent?

[ephemient]

https://github.com/ktorio/ktor-documentation/tree/2.3.10/codeSnippets/snippets/custom-plugin-authorization

[ursus]

not if I follow, I mean the part that attached auth tokens & refreshes tokens on 401 & retries the offending requests again

[ephemient]

ah that's the server side above. client is https://ktor.io/docs/client-auth.html#configure_authentication

[ursus]

I see, that's what I was looking for .. okay so my original intuiton was correct, move it to the higher abstraction, but ktor already has it, gotcha, thanks!

[yschimke]

Alpha.13 notes by Jesse speak to why https://github.com/square/okhttp/blob/master/CHANGELOG.md

[yschimke]

Notes from @jessewilson
>
> Breaking: Drop support for Kotlin Multiplatform.
>
> We planned to support multiplatform in OkHttp 5.0, but after building it, we weren't happy with the implementation trade-offs. We can't use our HTTP client engine on Kotlin/JS, and we weren't prepared to build a TLS API for Kotlin/Native.
>
> We'd prefer a multiplatform HTTP client API that's backed by OkHttp on Android and JVM, and other engines on other platforms. Ktor does this pretty well today!

[ursus]

yea.. I think it makes sense, I was surprised by the original announcement you guys want to do this

[yschimke]

There are bits that OkHttp does really well, some of the URL parsing that could be reusable KMP. And a desire to unblock libraries like coil. They unblocked themselves instead of waiting, ktor as the API which is not vaporware is the right choice for KMP clients.

[Tolriq]

Is there some kind of generic doc about migrating from okhttp to ktor? Specially all the single instance + newbuilder approach and all the different interceptors.

[ursus]

I'd need that as well, since I have bunch of (shallow copied) okhttp instances, which attach differenr interceptors - i.e. loggedOutOkHttp/loggedInWithAuthenticatorOkhttp etc

[ursus]

Soo, should I really start ditching retrofit in favor of ktor? No hope for retrofit going kmp?

[jessewilson]

Hope

[ursus]

Does it still make sense if auth is okhttp and that won't be shareable?

[Joel Denke]

@ursus Can always try ktorfit. https://foso.github.io/Ktorfit/ So that already work in KMP. I love Okhttp but more and more I leaning to run Ktor both in KMP and JVM only projects.

[yschimke]

Ktor will use OkHttp if you include ktor-okhttp. Which is worth doing. Otherwise on android you'll be losing features.