W3C home > Mailing lists > Public > public-html-comments@w3.org > December 2011

Re: Follow-up about PUT and DELETE in form methods

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 13 Dec 2011 21:24:09 +0100
Message-ID: <4EE7B469.7090803@gmx.de>
To: Cameron Heavon-Jones <cmhjones@gmail.com>
CC: thibault <thibault@miximum.fr>, public-html-comments@w3.org
On 2011-12-13 21:08, Cameron Heavon-Jones wrote:
> ...
> Yes, i understand what you mean here. It is reasonable though that these *may* be thought of\implemented as different resources, ie:
>
> http://www.example.com/index.html
>
> http://www.example.com/index.html?fragment=true
>
> Deleteing the first results in a full response, deleteing the second is a fragmented response from a fragmented version of the resource.
> ...

Now you are overloading the URI. There is only one resource here, and 
there's no point in assigning multiple URIs. URI overloading is almost 
as bad as POST method overloading :-).

>>> ...
>> Please translate?
>>
>> The client tells the server to DELETE. The server has several choices about what to return. It also has several choices what formats to use for that. These are orthogonal.
>>
>> We are going in circles.
>
> As described above, the state is defined through URI. The server doesn't have a choice as there is only 1 state the resource is in.

The URI identifies the resource. Period.

The preference about what information to get returned upon DELETE has 
absolutely nothing to do with the server's or the resource's state.

>>>>> It does work with XHR and form access if the Accept header is varied.
>>>>
>>>> It may work in *some* cases by abusing the Accept header.
>>>>
>>>>> ...
>>>>
>>>> Best regards, Julian
>>>
>>>
>>> I really don't think i can be accused of abusing the Accept header, if anything i hold upmost conformance. I just don't vary resource state.
>>
>> I really have no idea what you refer to when you say "vary resource state".
>
> By changing the content of the representation you have transferred a different state of the resource.

But in general, the payload returned in a DELETE response is *not* a 
representation of the resource identified by the URI. Actually, it's 
never for a succesful DELETE, because that implies that you have removed 
the resource.

Neither a status message "resource deleted" nor a fresh view of a parent 
collection are representations of the resource you have deleted.


>> It seems that you're missing that for methods other than GET and the most basic status codes, HTTP simply does not define *what* resource is being represented by the response. See<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-17.html#rfc.section.5.1>.
>>
>> The key here is to tell the server *what* resource you're interested in - not the format to represent it with.
>
> Yes, by URI - the Uniform Resource Identifier.

No, the request URI identifies the resource you want to DELETE. Not the 
resource that you want to be represented by the response.

>> Examples:
>>
>> DELETE:
>>
>> - a status message, possibly anonymous (without a URI)
>> - a progress resource after 202 (optionally with a URI)
>> - nothing
>> - a refreshed representation of the resource that "contained" the URI that was deleted
>>
>> These are *different* resources. They may or may not have their own URI.
>>
>> Best regards, Julian
>
>
> Possibly reframe as a single resource being returned in multiple forms of representation. In this regard they are all the same resource being represented according to client capability. The state is identified only by URI.

No, no, no. These are entirely different resources.

> We have reached some degree of clarity.

I'm not convinced about that yet.

Best regards, Julian
Received on Tuesday, 13 December 2011 20:31:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 13 December 2011 20:31:32 GMT