Prefer-Push, a HTTP extension.

[Evert Pot <[e-mail]>]

Hi everyone,

We're a group of people collaborating on a HTTP extension. We would like
to introduce a new header that a HTTP client can use to indicate what
resources they would like to have pushed, based on a link relationship.

This might look something like the following request header:

GET /articles
Prefer-Push: item, author

or

GET /articles
Prefer: push="item, author"

We see this feature being especially useful for hypermedia-style APIs.
Many of these types of APIs have some feature to embed resources in
other resources in a way that is ignored by HTTP caches.

The work-in-progress draft can be read here:

<https://github.com/evert/push-please/>

My questions:

1. Would this group be interested in adopting this draft and bringing
   through the standards process?
2. We're having some discussions around which HTTP Header is more
   appropriate. I'm curious if anyone here has any thoughts on that. The
   main drawback is using "Prefer" is that it requires parsing a nested
   format, but it might be more semantically appropriate for HTTP.
3. Our group is mostly divided on one issue: whether this header should
   allow a client to request pushes of arbitrary depth. The cost would
   be increased complexity (thus a higher barrier to entry). I'm curious
   if anyone here has any insights that would help us make this
   decision.

Arbitrary-depth example with a custom format:

  Prefer-Push: item(author, "https://example.org/custom-rel"), icon

Example with S-expression syntax:

  Prefer: push="(item(author \"https://example.org/custom-rel\") icon)"

In each of the above cases the client request the server push:

1. The resource(s) behind the item link-relationship
   a. The resources(s) behind the author relationship (via the "item"
      link-relationship).
   b. The resource(s) behind the "https://example.org/custom-rel" (via
      the "item" link)
2. The resource(s) behind the icon relationship

Unfortunately structured-headers doesn't support data-structures of
arbitrary depth, so if we want arbitrary-depth pushes, we would need to
pick a different format. Very open to suggestions here too.

We intend to have several working implementations of this. For those
interested in discussing, most of our discussion  is happening on a
slack instance (http://slack.httpapis.com channel: #push-please).

Evert et al.