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

On Fri, Dec 13, 2013 at 11:44:15AM -0800, James M Snell 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.

It'd be nice to have an XID header like any multiplex-capable RPC
protocol.

Given just XIDs an application could determine incoming request
dependencies all by itself.  Explicit dependencies would be nicer but we
probably don't want to push ordering of incoming requests to the server
-- just the app is good enough.

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

It's enough.  But more than that, it'd be nice to commit to not doing
things that might make HTTP/2.0 bad for RESTful APIs.

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

Eventually, yes.  If for no other reason than that eventually there will
be servers that only serve HTTP/2.0.  That may be many years away.

Also, I could see adoption by APIs being swifter than adoption by
websites.

Nico
--

Received on Friday, 13 December 2013 21:27:07 UTC