Use PUT vs PATCH to distinguish diff vs. full payload

[apparentlymart]

Currently it's left up to out-of-band information to differentiate between a publishing request that is a full payload or a diff. I think a hub should be able to switch between a full payload and a diff on a per-notification basis for the following reasons:

• Sometimes a resource changes to such a great extent that it is more efficient to send the full payload than to send a diff.
• If the subscriber does not have the resource to which the diff should apply, the hub can fall back on a full payload to reset the resource state.

If we switch from using POST to PUT and PATCH then we can make use of existing HTTP semantics to produce completely self-contained notifications that don't rely on outside information to be understood.

To be concrete:

• a full content notification would be a PUT on the notification URL with a Content-Type describing the format of the payload.
• a diff notification would be a PATCH on the notification URL with a Content-Type describing the patch format.
• For diff formats that are riskier to apply to an unknown resource state, ETag/If-Match can be used by the hub to help the subscriber recognize the mismatch.
• Where there is a resource state conflict, a hub can fall back on a PUT to reset the resource state for subsequent PATCH requests. This requires an in-band distinction between full payload and diff so that the hub can switch modes on the fly as required.

As a backward compatibility shim for 0.3, I'd suggest that a notification using the POST method be interpreted as a PATCH whose payload is either an Atom or an RSS feed, but any other content types MUST be sent as either PUT or PATCH.

For best results we could try to define a patch format negotiation protocol, but initially I think this could be left out-of-band as there is likely to only be one or two appropriate patch formats for a given resource and subscribers are generally tailored to a particular resource type.