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

On 13 December 2013 11:44, James M Snell <jasnell@gmail.com> wrote:
> 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.

... where *some* == most if not all.  If you assume that you are
talking about a single user context, then there are plenty of reasons
why you need to serialize requests.  I was talking about operating at
scale, with millions of users.  At that point, multiplexing is a huge
win.  When talking about thousands (or hundreds of thousands) of
requests per second, connection management in HTTP/1.1 is a major
cause of headaches.  Especially when there are a limited number of
peers involved (don't assume that all requests are terminated at user
agents, in these architectures servers make an order of magnitude more
requests than the final client.  HTTP/2.0 reduces overheads here
significantly.

> 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.

When you are at the point that you are saturating links, a few bits
does make a difference.  We never measured any performance benefits
from the binary encoding, but it can't be worse.

> 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?

So, you ask the question, then ignore my answer because clearly I
don't know what I'm talking about.

Received on Friday, 13 December 2013 22:35:19 UTC