HTTP/2 Push for APIs

HTTP/2 brought us the ability to push resources from server to client, before client knows they need it.

HTTP/2 push has had mixed success, up to a point where Chrome developers are thinking of experimenting with disabling it alltogether. I think this would be a huge loss for APIs, so I shared my thoughts on the IETF HTTP-WG mailing list.

I copied it in full here (slightly reformatted):

From: Evert Pot
To: ietf-http-wg@w3.org
Subject: Another PUSH defense: APIs

Hi everyone,

I wanted to chime into the discussion and share a different use-case for h2 push.

My background is mostly API development. In the last few years I’ve developed a number of REST-flavored services, most recently using the HAL format.

When looking at various hypermedia formats, they all tend to have something in common, the need to embed resources.

What this generally means, is that if you do a GET request on a ‘collection’, the response typically gives you information about the collection, but also every entry inside of it. If effectively embeds the representation you would have gotten if you had done a GET request directly on individual item in the collection.

Every one of those embedded GET responses has their own url, their own contents and their own list of links.

• HAL does this with _embedded.
• Atom does this with the <item> element.
• Collection+JSON does this with the items JSON property.
• Siren does this with the entities JSON property.
• JSON API does this via the relationships property.

Here’s an generic example of a fictional collection in a fictional hypermedia format.

HTTP/1.1 200 OK
Content-Type: application/json

{
  links: [
     { href: '/collection/1', rel: 'item' },
     { href: '/collection/2', rel: 'item' },
     { href: '/collection/3', rel: 'item' },
     { href: '/collection/4', rel: 'item' },
     { href: '/collection/5', 

Truncated by Planet PHP, read more at the original (another 7238 bytes)