Multiplatform OkHttp

[swankjesse]

OkHttp has two roles:

• An HTTP client API. Includes types like Request, Response, HttpUrl, and MediaType. Lots of visible design decisions here like whether a partial URL is representable, how much abstraction we layer on TLS, and what we include ourselves vs. delegate to JDK APIs.

• An HTTP client engine. This is an implementation detail that performs the HTTP/1 and HTTP/2 calls. Lots of design decisions are hiding in here, including behavior of retries, timeouts, limits, and resource pooling.

When we shipped OkHttp 1.0 it was an engine only, borrowing HttpURLConnection as its API. We've implemented the Apache HTTP API on our engine. Ktor can also use OkHttp as its client engine.

And in this 2019 blog post, Uber described using OkHttp’s API with cronet as the engine.

Let's start with a multiplatform HTTP API only. We can facade existing engines on native and JS.

[yschimke]

Should 5.0 of the KMM version be experimental? Likely to change in 5.1? Can we get it right in the first release?

I'm working on the assumption that this is still a strictly no breaking public API changes for JVM.

As discussed in Slack, it's a good opportunity to shrink some public APIs for classes, avoid anything deprecated in the JVM moving into common.

Complex types like X509Certificate deserve a lot of thought to get right and are exposed in very central types like Handshake.

[yschimke]

@swankjesse is 5.0 a good point to add a -kt module with await() suspending methods?

[swankjesse]

@yschimke with 5.0 we'll ship a tiny subset of our API as multiplatform, and expand coverage in subsequent releases. As long as we don't introduce new APIs we're unlikely to have regrets.

[yschimke]

This is probably complete enough to make a standard client call. (handshake isn't there, challenges are missing) But much of that is presumably provided by the native implementation.

[yschimke]

@swankjesse should ktor be our validating Client implementation? Will give us 100% coverage. But where to live? okhttp-ktor? Or a separate Block Inc. project?

[swankjesse]

We could use MockWebServer on the JVM to validate all platforms. Ktor won't really work cause it won't let us simulate errors.

[yschimke]

I meant client. Interesting idea using mockwebserver, can you run it from a jsTest without making it multiplatform? Basically what proves that an OkHttp 5.0 with multiplatform Call.Factory but no implementations is working?

[swankjesse]

Ahhhh... I think we should do our own direct binding to browser JS APIs.

For MockWebServer... we would connect to it via HTTP!

[yschimke]

But you don't have apis like MockResponse then.

[yschimke]

I think we have the API part in 5.0 now. Obviously work there is ongoing like IDN, but effectively working in typical cases.

[PaulKlauser]

Since KMP support was dropped in 5.0.0-alpha 13, should this issue be re-opened?

[swankjesse]

There’s still some KMP stuff I’d like to do. Shipping HttpUrl for KMP would be pretty rad.

[swankjesse]

#8578

[yschimke]

I think it's right to keep this closed, it isn't a broader aim. But +1 to letting the useful bits solve thorny problems for KMP.