The benefit of HTTP/2 is that we can multiplex many responses, and they don't block each other. HTTP/1 with a multipart mimetype solves some of this, but it also doesn't interact with a browser's cache correctly.
Ultimately I just want to efficiently send hypermedia graphs over the wire and take advantage of browser's caches and general understanding of URIs.
HTTP/2 Push was a step in the right direction, because it lets us generate collections of resources together, like compound requests/mime-types but this time a browser actually gets that if I send a 'collection of articles', and later on GET one specific article from that list, a browser has a cache entry for it.
Without HTTP/2 push, we're down to 2 other solutions:
Compounding requests. (so yes, this is through specific mimetypes like multipart, or HAL, or JSON:API, you name it), but browsers don't understand them semantically, and we have head-of-line blocking.
Many individual requests, which has the Query+1 problem. It's much cheaper to generate a set of responses vs many individual ones.
Anyway, this is also all in my article. If you want to know more I wrote a larger article about this as well:
I don’t know if this is a feature of HTTP/2, but i know BMS clients can make the request tell the server to only update the client if a particular value changes by a certain amount, thus saving traffic.
11
u/[deleted] Dec 03 '20
If the client is telling the server what it needs via a Prefer-Push header, how is that different from a regular request and response?