Re: Non-browser uses (was Re: disabling header compression)

I am a developer who has been looking forward to http2 and helping support
it for non-browser clients via okhttp.

I gained interest through dealing with various cloud apis, some of which
restful, consumed through the apache jclouds and netflix denominator
projects I founded.  All of which could be helped by http2 directly or
indirectly.

Indirectly, one would hope both client and server sides will be more
scalable due to less tcp connections and efficiency within them.  Lack of
scalability has resulted in some cases with arbitrarily low, defensive api
quotas.  Imagine running amazon sqs.. http2 seems a nobrainer win for this
reason alone.

Also common is the cancelablity.  Programming constructs such as
Future.cancel or Subscription.unsubscribe are not effective in http1.
Basically you can nuke the socket.  GOAWAY is awesome.

If I had a nickel for every state polling loop... Imagine a HEAD push
promise to invalidate state (thanks jeff pinner for the idea).

What about inlining? How many rest api designs have inlined around
roundtripping concerns? Clearly, this is the same benefit to non-browsers
as browsers.

We also heard an interesting use case about prioritization for netflix
video traffic... that isn't really a browser concern.  I'm sure I have also
forgotten a bunch of other values, too ;)

Anyway, I am sure there will be doubt about the value of http2 for apis, or
concern that it can make bad developers worse.   I certainly would prefer
to give it a shot.  It makes too much sense not to.

As a part of this decision, I know I have to roll up sleeves and get
libraries and servers working.  Luckily, so are others, and moreso than
me.  Tooling and success stories will hopefully pave way to non-browser
developers innovating their stacks with http2.

-A
On Dec 13, 2013 11:30 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

> On 13 December 2013 10:48, James M Snell <jasnell@gmail.com> wrote:
> > On the question of adoption. Let me pose this question: what benefits,
> > if any, does adoption of HTTP/2 offer to developers of HTTP-based
> > RESTful APIs? What significant problems does HTTP/2 address that would
> > justify the implementation costs? (Or is this another, "well they can
> > just keep using HTTP/1" answer?)
>
> I don't think that I'm alone in this, but the bulk of my day job at
> Skype was building those sorts of systems with what you call "RESTful
> APIs".  Having HTTP/2.0 was identified as a being hugely important to
> the long term viability of those systems.  The primary feature there
> was multiplexing (reducing HOL blocking is a big win), but we did also
> identify compression as important (and potentially massively so).  We
> were also speculatively interested in push for a couple of use cases.
>
>