3 ms·
Push was just an example. HTTP2 is fundamentally different from HTTP; it's more akin to TCP in L7. Can applications take advantage of this fundamental paradigm
by jimktrains2 10y ago
Push was just an example. HTTP2 is fundamentally different from HTTP; it's more akin to TCP in L7. Can applications take advantage of this fundamental paradigm shift? What about for non-browser clients (api clients)?
- danudey 10y agoNothing that HTTP/1.1 and websockets can't do, really.
- jimktrains2 10y agoSure but then you have a websockets interface , is there something similar for http2 that breaks the resource requests-resource response model?
- jkarneges 10y agoServer push is pretty much the only real difference from an interface perspective. Otherwise HTTP/2 is semantically the same as HTTP/1.1, just with certain optimizations like header compression and multiplexing. I don't think we'll see many applications built on top of HTTP/2 libraries wanting to directly control that kind of plumbing. Even server push can be abstracted away via a cache. Pushed resources fill the cache, and when the application tries to fetch those resources the underlying HTTP/2 library could return the cached resource. This should be quite interesting to API clients, so that services don't have to make aggregate resource endpoints just to avoid round trips. I do think future applications will want to have code triggered when a pushed resource arrives, though. I'm not aware of anyone doing this but it could be an interesting alternative to long-polling or streaming. That said, long-polling and streaming become very attractive within HTTP/2 as well, so it'll be interesting to see what developers end up doing.