Aws-sdk-java-v2: OkHttp HTTP Client Implementation

[codefromthecrypt]

Expected Behavior

I was excited about the new SDK and immediately looked for OkHttp. This is an easy library to work with that rarely breaks compatibility.

Current Behavior

If you search the code there is no okhttp

Possible Solution

support okhttp alongside apachehc and netty

Context

Instrumentation, especially tracing is well designed in OkHttp. Supporting would arm your SDK with more tools.

[swankjesse]

Should be a pretty straightforward conversion. OkHttp’s APIs map directly to the HTTP abstraction here, with one challenge.

The SDK gets request body bytes by asking callers to return an InputStream. OkHttp does it by asking callers to write to an OutputStream. To map from one approach to the other you’ll need to fully buffer the request (dangerous) or use a Pipe (extra context switches).

[millems]

Mapping from the InputStream to the OutputStream should be okay for sync clients, since the HTTP implementation can just IoUtils.copy(inputStream, outputStream) with each request thread.

What benefits would you get from an OkHttp implementation that you don't currently get from the Apache or UrlConnection client?

More options is definitely nice, but we need to compare that benefit to other pending 1.11.x-parity features, like presigned URLs, transfer manager, etc. Quantifying that benefits helps us with prioritization.

[codefromthecrypt]

I'll answer from a pure feature POV, but also remember that there are ecosystem reasons. People generally don't like not using an extremely popular http library. There are very very few java libraries with 30k stars on github for example, it is quite odd to not include such a plainly desirable tool. Likely someone else will anyway if they haven't already, just it is easier on the ecosystem if you support it OOB.

From an observabilty standpoint apachehc is difficult. For example interceptors don't close over everything leading to "dark spots" that have cause trouble in tracing. I opened (#852) about that as the previous SDK if you tried to trace it had places where errors could raise in no way to fix except agent instrumentation. apachehc has also changed versions occasionally making library conflict likely for applications.

UrlConnection is an answer, but not a great one. It is even worse for observability and has significant design issues noted here and elsewhere.

On its own, netty is great. I'm happy people can choose it, but it still won't be appropriate for all. Netty can be a difficult dependency to match with other tools. For example, grpc has a somewhat fragile chart explaining which versions of this and that work for a narrow version of netty.

Specifically what I mentioned about okhttp is an excellently designed event listener This will help your team, too. I would be surprised if the x-ray team didn't find this easier to do tracing with.

We can take lessons if we like from Spring who if you support OkHttp, you'd support the OOB options present there for RestTemplate (ClientHttpRequestFactory). Those in spring will then not have to accidentally configure a different library than their primary for web services communication.

I doubt people would find surprising the act of supporting okhttp in other words, and it certainly will help some from having to incidentally configure a different http client engine that works differently than their other web services code.

Hope this helps!

[millems]

Thanks for the detailed response!

[swankjesse]

Also OkHttp comes with HTTP/2 support!

One small request: if you add APIs to do an OkHttp integration, can you allow end-users to provide their own OkHttpClient instance to the SDK? Perhaps via your Builder?

OkHttpClient has several configuration options (interceptors, event listeners) that don't apply to all HTTP clients but would be a big loss to go without.

[shorea]

We push configuration to the implementation level so each implementation can choose to expose the options it supports. Generally we create a facade builder that matches are conventions and delegates down to the builder/configuration of the HTTP client. That said it would probably be useful to also have an option to use an already built OkHttp client for configuring settings we don't support yet or perhaps some more advanced stuff like proxying or sharing that instance with non-sdk consumers. See a somewhat related discussion in https://github.com/aws/aws-sdk-java-v2/issues/852.

[ryonday]

Any chance of supporting the new JDK11 HttpClient?

[millems]

We should create a separate issue to track, but we'd love to support the new JDK11 HttpClient. In my opinion, it's near the top of HTTP clients we should support, because of the cold start benefits it would provide over Netty.