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 18:01:46 +0100
Message-ID: <4EE784FA.6080205@gmx.de>
To: Cameron Heavon-Jones <cmhjones@gmail.com>
CC: thibault <thibault@miximum.fr>, public-html-comments@w3.org
On 2011-12-13 17:54, Cameron Heavon-Jones wrote:
>
> On 13/12/2011, at 4:29 PM, Julian Reschke wrote:
>
>> On 2011-12-13 17:09, Cameron Heavon-Jones wrote:
>>> ...
>>> Let's leave WebDAV alone. What is the use case we're discussing then if not how WebDAV servers return a status message for WebDAV client and full html representation for browsers over the same "Accept" header?
>>> ...
>>
>> For instance, a UI that allows deleting resource both through a script-less form (where you need a new HTML page to be displayed as result), and a script-driven XHR based UI (where you only want to know success/fail). Note that in both cases the same user agent makes the request, but it has different requirements on the response type.
>
> This is exactly where "Accept" should be used. Either the script should advertise it wants "text\plain" status message or maybe an "application\json" response.

The media type of the response isn't relevant here. "Accept" is the 
wrong header to negotiate on. Sorry.

>>>> Also, Content Negotiation via Accept: doesn't help here. Accept: is for negotiating the media type of the response, not what it describes. We need a different hook.
>>>
>>> Content negotiation is a valid (and the only) way for determining whether to send html or not.
>>
>> It depends on what request header is used for negotiation.
>
> while it is possible to vary on another header, it is not desirable. this is relatively immaterial for this discussion tho.

Sorry?

>>> You want to send different html based on who the client is. This is bad ReST, IMO.
>>
>> Wrong.
>>
>> I might agree if this was about GET, but it's not. What needs to be negotiated is not the media type but something else; *what* the response should represent (the status of the request, the new state of the resource, whatbot). Keep in mind that in general, the response to a request other than GET is *not* a representation of the addressed resource.
>>
>
> yes, you are negotiating the representation. i have no problem with any of this but as a recommended practice i would not vary on anything other than "Accept" and question why a user of one html-client should see something different from a user of another html-client.

What needs to be negotiated is *what* is represented (a status message 
as opposed to current state as opposed to...), not the format.

> ...

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

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