HTTP PUSH

# Push model #

* Node A is the authoritative source on some resource R
* Node B is interested on R's state
* Instead of B doing a GET on A (pull) we use a push model where A does a PUT on B
  * HTTP roles are reversed - the HTTP client doing the PUT (node A) is authoritative for the resource R
  * A decides the most appropriate times to do this push
  * A is also the authoritative source on R's ETag
    * A includes this ETag as a *request* header on the PUT (which is odd, since ETag is defined as a response header on the HTTP spec)
    * B doesn't know how to compute the ETag. For instance, a GET/HEAD to B will return the ETag PUTed by A 
* A can make conditional PUTs on B using `if-none-match: current-A-ETag`
  * This allows A to be stateless regarding the synch state to B, i.e., A doesn't need to "remember" if it already PUTed the last state to B or not.
* How does A know the URI where to PUT?
  * Option: "out-of-band" knowledge, which isn't hypermedia driven
  * Option: there is an explicit subscription done by B to A that contains B's URI (possibly an URI template if there are multiple resources)
* Used in "server-to-server/machine-to-machine" scenarios.

# Comments/critiques welcomed #
  

two brief comments:

• my messenger pigeon maybe was a bit extreme. but what we see in reality is a whole bunch of (often unreliable) push mechanisms: APN, SMS, email. as long as the message relates to a globally identified resource, it can have utility.
• i like the ETag used this way. right now it is defined as a response header: https://tools.ietf.org/html/rfc7232#section-2.3. it might be useful to write up the things you wrote in a draft to make sure how interactions with it as a request header are working. interested in doing this?

• Yes, I would be interested.