Lately I've been building HTTP APIs for Square Cash, to be used by our website and partners like Snapcash. It turns out this is a particularly difficult task because I need to balance two competing concerns:
Keep separate things separate. If the app wants to look up payments 123, 246 and 369, it should make three requests for /payments/123, /payments/246, and /payments/369. This is simple and manageable, but it means both client and server need to pay HTTP call overhead for every payment. That slows down the experience and increases our datacenter load.
Batch things up. REST APIs are nice and all, but what's going to run fastest is a aggregating everything into a single call. Perhaps it’s /payments-list/123,246,369 and now there’s more APIs to worry about, but fewer calls.
Since /payments-list/123,246,369 doesn’t quite identify a resource, batching things also makes it more difficult to use HTTP caching. If the browser later wants to load payments 246 and 482, the URLs won’t match and we have to do our own caching in the application layer.
Enter HTTP/2
By significantly lowering the per-call overhead, we can use the simpler APIs without the drawbacks. HPACK header compression and multiplexing are important technologies that are going to make it easier to build HTTP applications.
OkHttp 2.3 supports the final HTTP/2 spec. It already works great with Twitter and Google HTTP/2 servers, and will work with others as they are deployed. Sibling project MockWebServer also supports HTTP/2 and interoperates with the latest Firefox and Chrome.
Get it
The changelog has full details of what's new & what's been fixed. Get 2.3.0 from Maven Central:
<dependency>
<groupId>com.squareup.okhttp</groupId>
<artifactId>okhttp</artifactId>
<version>2.3.0</version>
</dependency>