Change JVM backend

[hmil]

The current JVM backend (HttpURLConnection) has too many drawbacks including:

• No PATCH method (or any other non-standard method as a matter of fact). See #67 for a workaround
• No request bodies where the spec doesn't allow them

Must look for a replacement which is more loose on the spec.

[easel]

I have a few thoughts on this issue. One benefit of the library as it stands now is that it does not bring in bunch of extra dependencies. This is a good thing, and given you've made everything almost work with blocking java.net it doesn't make a lot of sense to through it out.

Instead, we could adopt a type class approach for the driver implementations. It would require an "import tax" or DI someplace to set up the driver initially, but it would allow a bunch of backend implementations, each in their own package with their own dependencies.

Long term, I'm 99% sure both Akka HTTP and AsyncHttpClient are going to be desirable. My guess is Apache HTTP Client 4 would be desirable to some as well, IIRC the AWS SDK uses it for example.

[ebruchez]

I got here because I was wondering which backend is used on the JVM.

I appreciate that just depending on HttpURLConnection has the benefit of minimal dependencies and will work for small projects, but otherwise it seems to be a dead-end.

The Apache HTTP Client (AKA Apache HttpComponents) is probably still the most popular implementation of an HTTP client. It's also what everybody uses on Android, and what the Google OAuth for Java uses. I think that it is fairly likely that as a project grows it will end up depending on Apache HttpComponents.

I notice by the way that there is work on version 5 of Apache HttpComponents ("lays the foundation for transition to HTTP/2 as the primary transport protocol in the future releases"), so it seems that it's where the future lies as well. I don't know if there are other solid competing projects for HTTP/2 on the JVM.

I am not complaining by the way, just supporting the idea that switching to another backend or configurable backends would be desirable.

[ebruchez]

I just found out about the Google HTTP Client Library for Java. It features a "Pluggable HTTP transport abstraction that allows you to use any low-level library such as java.net.HttpURLConnection, Apache HTTP Client, or URL Fetch on Google App Engine.". Could be worth considering.

[hmil]

Thanks for this insightful feedback.

As of v2, I am no more actively working on the library. Contributions are more than ever welcome and I am willing to provide support if anyone wants to work on this enhancement.

[ebruchez]

@hmil Thanks for the heads-up.

[hmil]

There might be great potential to address this issue using netty or akka. These backends are asynchronous which means they behave more like JS networking. Thus using such backend could potentially reduce the gap between JS and JVM implementations both for correctness and performance.