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

Am 05.02.2008 um 03:40 schrieb Mark Nottingham:
> I don't think that does the trick. APP creates multiple resources  
> and returns a 201 with a Location of the "Member entry URI",  
> mentioning that other resources could have been created in the  
> process.
>
> So, a 201 can imply the creation of one or more resources; if the  
> response contains metadata (e.g., Location, ETag), they are  
> associated with the most important one, in the judgement of the  
> server.

When thinking about a good wording for this, I stumble into the tar  
pit of defining "cause" and "effect" for a http application that is  
unknown. Trying to sort this:

- resource are created on a server all the time. Even a DELETE may  
create a resource, e.g. a record of the action. A PUT on an existing  
resource may do the same (implicit versioning in DeltaV). These  
actions however will not result in a 201 response.
- A 201 response is sent when the server wishes to inform the client  
that, as a consequence and in direct relevance to the request, the  
Location resource was created.
- In this light a "201" dies *not* describe a side-effect but a  
server state change that is in direct connection to the request,  
relevant for the client to know in the context of the request and  
often even the *only* possible success code for the request.
- The term "side effect" in 9.1.2 in 2616 is problematic. It has  
caused many myths about GET. A GET can have side-effects on the  
server (writing access.log, updateing statistics pages). But none of  
these side effects should be of relevance to the client, nor can they  
be expected, nor a are they reproducable. There is no statistical  
correlation between a GET and the resource changes on a server.

So,

- a 201 response informs the client that "a" resource has been  
created (maybe more)
- a Location header informs the client of the URI of this new  
resource (if missing the URI is the one of the request???)
- a ETag header on the response indicates the current value of the  
entity tag for this requested variant (request uri or location)


//Stefan

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

Received on Tuesday, 5 February 2008 09:19:50 UTC