Consider committing to using OkHttp in preference to HttpURLConnection

[rtyley]

This blogpost explains the advantages of OkHttp's interface over HttpURLConnection - it neatly supports separation of Request and Response, and offers an asynchronous Call interface:

http://corner.squareup.com/2014/06/okhttp-2.html

In order for github-api to take full advantage of the superior OkHttp API - and to expose it to external users so that users can do async calls to the GitHub API - would probably require commiting to using OkHttp everywhere within the github-api library, removing all usage of HttpURLConnection. This might feel like a big change, but it's mostly an internal one, so hopefully would not substantially impact consumers of the library, other than offering them additional functionality.

Amongst it's many consumers, OkHttp is also the engine that powers HttpUrlConnection as of Android 4.4, so it's a library that has a lot of traction and support.

See the OkHttp 'Recipes' documentation for code usage examples.

Would there be any interest in a pull-request that made this happen?

[kohsuke]

I'm open to be persuaded, but right now my feeling is that the cost outweighs the benefit.

• As you say, the use of HTTP API in this library is mostly implementation detail. Forcing OkHttp doesn't seem to help users.
• OkHttp jar file is around 300KB ish, and github-api jar is 175KB. That's a big dependency to pull in. And in other projects I work on, such as Jenkins, I always felt silly that I need so many different HTTP libraries in my transient dependencies.

I assume the main motivation for you is to be able to expose asynchornous operations, but that'd require a vastly different API surface, as all the methods exposed today in this library is fundamentally synchronous. What kind of API do you foresee that leverages the underlying asynchrony? How do you benefit from that?

[rtyley]

I don't really have solid answers to the questions you pose, just thought using OkHttp in preference to HttpURLConnection was worth considering!

As you say, the use of HTTP API in this library is mostly implementation detail. Forcing OkHttp doesn't seem to help users.

One thing that OkHttp does, that I'm not aware of other libraries doing very well, is the caching-support for conditional requests. Reducing the consumption of API quota definitely is of benefit to users- I'd almost be prepared to argue that the majority of users should be using it, so surely the majority of users are going to need OkHttp anyway... 😄

I assume the main motivation for you is to be able to expose asynchornous operations, but that'd require a vastly different API surface, as all the methods exposed today in this library is fundamentally synchronous.

The interface of HttpURLConnectionis a bit honky, so you might argue that being able to use the saner interface of OkHttp's Request and Response would be a reward in itself. But yep, the benefit of async calls is what I'd really like, and to take advantage of that would require a major change to the API surface of the API. Calls that previously returned a hard value would have to return a future of that value instead...

[KostyaSha]

Helped me to avoid rate-limits :) Bad that it doesn't support in-memory cache configuration.

[kohsuke]

I've filed conditional request support as #168. I'm closing this issue as WONTFIX.