On 13/12/2011, at 5:31 PM, Julian Reschke wrote:
> On 2011-12-13 18:21, Cameron Heavon-Jones wrote:
>>
>> On 13/12/2011, at 5:01 PM, Julian Reschke wrote:
>>
>>> 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.
>>>
>>
>> What are the "different requirements on response type" if not the media type
>> of the response?
>
> The media type of the response is orthogonal to what *kind* of response you
> want.
>
> For a successful DELETE, all of the following a plausible:
>
> - no response at all (204)
>
> - a short status message ("deleted x and all depending resources")
>
> - a representation of the collection the resource was removed from
>
> - ...
>
> None of these have anything to do with the *media type*.
>
Yes they are all plausible responses, but do need they *ALL* need to be
returned for each resource and same "Accept"?
Personally i would map this as follows:
No Accept Header => 204
Accept: text\plain => short status message
Accept: text\html => representation of the collection
I understand this may not be possible for existing implementations of servers
and clients. My stance is that if you are to perform client based
content-negotiation you might as well just vary on User-Agent header, it
amounts to the same thing and is a bad practice, IMO :)
i understand the need for some applications to have greater fidelity over the
content of their representations however i believe this is better addressed
through URIs.
>
>> No, sorry. With all due respect, I am in complete disagreement with you
>> here. Perhaps others can try different tacks to convince either one of us
>> but this is where we left it last time and looks to be just one of our
>> unresolvable understandings.
>
> Indeed.
>
> > ...
>>> What needs to be negotiated is *what* is represented (a status message as
>>> opposed to current state as opposed to...), not the format.
>>
>> I disagree with negotiating *what* is represented within a single format and
>> that this is of relevance to form specification.
>>
>> If the Preference token is not enough can you please state what additional
>> problem must be addressed?
>
> Oh, a Prefer token would be enough, we just need to specify it, and make sure
> that forms either send it automatically, or the author of the form can
> specify it.
>
> Best regards, Julian
I have no problem with this at all, and (just quietly) you could even get it
past me to get it automatically applied because i just don't care that much
about something that can be ignored :)
Can we say this has been put to rest (pun intended)?
Thanks,
Cam
