It's more a general question than specific to okht...

# squarelibraries

[Lilly]

It's more a general question than specific to okhttp, but when Android only provides HttpURLConnection as http client, every 3rd party has to be based on HttpURLConnection and so okhttp too or not? But since Android 4.4 HttpURLConnection uses okhttp as http engine. This confuses me a bit. Does that mean okhttp is not based on any other API and is written from scratch? Can someone enlighten me please?

[jw]

OkHttp is built around Socket

[jw]

HttpUrlConnection is also built around Socket

[jw]

I would recommend listening to the ADB Podcast with Jesse Wilson

[Lilly]

I already checked the source code. Tbh... don't know what's going on there.

OkHttp is built around Socket

So java.net.Socket is lower-level than HttpURLConnection, right?

[ephemient]

it doesn't have to be; Cronet provides a URLStreamHandlerFactory that would make HttpURLConnection based on native code, bypassing Java's Socket. but the default one is

[jw]

Yes I'm simplifying. A cronet impl exists for OkHttp, too

[jw]

The person clearly only had a cursory understanding of the moving bits so there's no need to be absolutely precise. Hell, trying even explain how OkHttp was forked from Android and then re-included as a standalone library behind the API it was forked from is already confusing.

[ephemient]

it is confusing, true

[ephemient]

so basically (with few exceptions) all networking ultimately builds atop Socket which is the lowest level you get from within Java

[Lilly]

ok cool, thats understandable. Only one thing is unclear:

HttpUrlConnection is also built around Socket

I found a tweet from 2014 where you (Jake) state "OkHttp became the engine that powers HttpUrlConnection as of Android 4.4". So I would expect HttpUrlConnection is built on okhttp or did you mean that because when HttpUrlConnection is built on okhttp it's in turn built on Socket (HttpUrlConnection -> okhttp -> Socket). Please correct me if iam wrong.

[jw]

Ok let me try to state this as a series of discrete steps.

In the beginning of (Android's) time, HttpUrlConnection was an HTTP implementation built around Socket. Jesse Wilson worked on this client on the Android team.

Jesse left Google and joined Square, and around the same time he took the open source HTTP client which powered HttpUrlConnection from Android and moved it into a standalone library. This way you could ship it with your app and every OS version would see the improvements.

In Jesse leaving Google, the HTTP client built-in which powered HttpUrlConnection stagnated. OkHttp thrived and gained many more features.

Eventually, Google decided to throw away their build-in HTTP client powering HttpUrlConnection and instead forward HttpUrlConnection to OkHttp behind the scenes. That happened in Android 4.4. It's still the same HttpUrlConnection API, but now it's OkHttp's codebase behind it rather than an HTTP client which is part of Android itself. (Although, technically, that version of OkHttp becomes part of Android since each Android version has a fixed version of OkHttp).

[ephemient]

Android also used to ship Apache HttpClient, but that also stagnated and got deprecated instead of being updated. I guess it's harder to remove HTTPUrlConnection :)

[jw]

Right. Technically you can't remove either of them, but Android will hide Apache HTTP from you if your targetSdkVersion is high enough.

[Lilly]

wow thanks for the good explanation. So theoretically I could use HttpUrlConnection without facing any drawbacks (because it forwards to okhttp) while the benefit I get by using okhttp directly is a simpler API with kotlin sugar on top, did I get this right?

[jw]

well, kinda. unfortunately it's even more complicated than that in practice!

[jw]

the design of HttpUrlConnection means that it will only work for HTTP/1. It is impossible to use with HTTP/2 and beyond. Additionally many of the knobs to tune it are global so you can't have two versions for two servers that you connect to. OkHttp has its own API to solve all of these problems.

[ephemient]

if you ship your own copy of okhttp, you get to use features that aren't available via the httpurlconnection interface, and (assuming your app updates more often than android releases) you'll be more up to date

[Lilly]

Good point @ephemient . ok so even if I have a small app with just some GET requests okhttp is always the better choice

[Lilly]

Thanks for your time guys, really appreciated

[yschimke]

I'm going to regret mentioning this, but there are also some specific (probably broken) situations where OkHttp using Conscrypt (the android SSL engine) ends up causing HttpUrlConnection requests to check certificate revocation lists. But let's ignore this until it hits you for real.

[Lilly]

Thanks for mentioning @yschimke