W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: James M Snell <jasnell@gmail.com>
Date: Fri, 13 Dec 2013 11:44:15 -0800
Message-ID: <CABP7RbfLOKACsH-YvRb=Ed--Q4aN7g-=SzSdFzO6sPHGvWhZ9Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Peter Lepeska <bizzbyster@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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?

- James
Received on Friday, 13 December 2013 19:45:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC