If you are going to allow for a response that doesn't necessarily need to
change the requesting page should there be an onDelete, onUpdate, and possibly
onPut handler for a form tag? The page creator could always indicate via
javascript a page to redirect to upon getting a 202 response. One might also
argue for the use of the same thing for post and get as well; onGet, onPut.
This would also mean that javascript could replace contents of a div on a page
based on the response if page developers wanted to create more 21st century web
experiences that don't reload everything for something relevant to a section of
a page.
If you do that it would probably also nice to have javascript access to the
object doing the transfer so that one could provide either a progress bar or
busy indicator in the page. Something like
getElementByID('myform').transfer.bytesSent,
getElementByID('myform').transfer.bytesReceived,
getElementByID('myform').transfer.complete,
getElementByID('myform').transfer.response.
This is probably dangerously close to implementing state in a web document, but
you can't blame a guy for trying.
Arthur Clifford
On Dec 13, 2011, at 9:48 AM, Cameron Heavon-Jones wrote:
>
> 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
