RE: i69: Clarify "Requested Variant" [was: New "200 OK" status codes, PATCH & PROPFIND]

Mark Nottingham wrote:
> PROPOSAL: Define the response to PUT, POST, DELETE, and 
> OPTIONS to carry a "status message," not a representation, 
> UNLESS a Content- Location is present OR (in the case of 
> POST) there is explicit freshness information. As such, 
> ETags, etc. do not apply to them.

If there is a Content-Location, then that means that a representation of
the response body may be retrieved at the location given in it. That is,
the status message is stored on the server along with whatever resource
was being manipulated. If Content-Location = Location (for 201), then
resource being manipulated is the same as the status message (the
resource describes its own status). For some methods (e.g. PUT),
Location is implicitly the Request-URI. If Content-Location <> Location,
then the status message is a seperate resource from what was created,
and a representation of that status message is available at
<Content-Location>. You cannot make "status message" and
"representation" mutually exclusive. Status messages can also have
multiple representations if there is a Content-Location header (using
normal content negotiation at the Content-Location URI). And, a server
cannot return a representation of the manipulated resource *instead* of
a status message; if it returns a representation of the manipulated
resource, that representation *is* the status message.

> PROPOSAL: Remove 'requested variant' from terminology and 
> define 'selected representation' as (roughly): "The 
> representation that would be returned by the server if the 
> request method were GET, taking into consideration selecting 
> headers, as specified by the Vary header's payload."

If there are Accept-* headers, then those headers apply to the response
body (status message), not to the POSTed/PUT/DELETed resource. For
example, "Accept-Encoding: deflate" on a POST means that the server can
return a compressed status message.

This proposal seems to be saying that those headers are used to select
two representations of two different things at once: a representation of
the status message, and a representation of the resource(s) that are
being manipulated. The assumption is that the client will always send
the same Accept-* headers for the hypothetical GET that it sent during
its actual POST/PUT/DELETE. I don't think that assumption is valid.

> PROPOSAL:
> A 201 response MAY contain an ETag response header field indicating  
> the current value of the newly created resource's selected  
> representation ETag (i.e., the ETag that would be returned if 
> the same  
> selecting headers had been sent in a GET request to it).

The above implies that only one resource was created. "the newly created
resource" should become a reference to the resource pointed to by the
Location header. Also, the hypothetical GET would have to happen on the
Location URI, not the Request URI, right?

> > 14.25 (If-Modified-Since)
> > 14.28 (If-Unmodified-Since)
> > 14.29 (Last-Modified)
> 
> PROPOSAL: s/requested variant/selected representation/g; s/variant/ 
> selected representation/g

When I POST with an If-Unmodified-Since or If-Match to an AtomPub
collection, doesn't that mean "Process this new entry only if the
collection hasn't been modified"? In other words, If-* headers must
refer to the resource that is available via a GET at the Request-URI--in
the case of AtomPub, the collection feed.

- Brian

Received on Wednesday, 13 February 2008 14:19:55 UTC