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

Brian Smith wrote:
> 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

...not necessarily stored, but made available.

> resource being manipulated is the same as the status message (the
> resource describes its own status). For some methods (e.g. PUT),

The representation sent back (not the resource) is the same as the 
status message.

> 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.

Yes. Does this really conflict with Mark's proposal though?

>> 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.

Well, it applies to the response, be it a representation or a 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.

I think it is in practice.

If content negotiation occurs, it's the server's responsibility to make 
sure that PUT and DELETE behave in a sane way. That can be done by 
disallowing them (just supporting them on more specific URIs), or by 
doing the "right" thing (DELETE without Accept-Encoding also removes a - 
for instance - gziped variant).

>> 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

Yes (with the special case for PUT).

> Location URI, not the Request URI, right?

That's tricky. I'd prefer this to only be based on Request-URI and 
request headers.

>>> 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.

I think this is what the proposal says.

BR, Julian

Received on Thursday, 14 February 2008 13:22:09 UTC