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

On Fri, 13 Dec 2013, James M Snell wrote:

> On Fri, Dec 13, 2013 at 11:27 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.
> 
> Multiplexing is a win in *some* restful API cases; It is quite
> dangerous in others. For APIs that rely on mixing sequences of
> non-idempotent requests, multiplexing can be a major problem if
> optimistic concurrency is not properly implemented, and even then
> could cause significant problems if interdependent requests flow out
> of order. I do agree that multiplexing helps significantly with APIs
> with predominantly independent request flows.
> 
> Header compression, however, is at best a "nice to have". I'm all for
> sending fewer bits down the wire, but the header compression mechanism
> itself provides no direct benefit to the REST API developer who is
> still required to deal with arcane, overly verbose header field value
> formats, encoding schemes and ambiguities. The only benefit realized
> at that level will be improved performance.
> 
> Any benefits Push may offer are, at this point in time, far too
> speculative to be worth discussing.
> 
> My take away from your response is that, so far, the only benefit
> HTTP/2 will have to offer RESTful API developers is improved
> performance in some scenarios and fewer bits sent over the wire on
> average. My question is: is that going to be enough to warrant broad
> adoption among that group of developers?

I see the binary well defined data flow structure as a big win and w/o
header compression  or encryption to implement, quite possibly easier
to implement than http/1.x. Many of those developers will depend on
toolkits just like they do today. In that case, what becomes important
will be the processing burden on the device and perhaps debugging.

Received on Friday, 13 December 2013 20:37:32 UTC