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

On 13/12/2011, at 6:10 PM, Arthur Clifford wrote:

> 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?

Doesn't this break the request\response cycle? After form submission the page should have no callbacks, the response defines browser behaviour but the originating page is now out of context.

For XHR i can see value in intercepting responses from the same domain, i think this might have been brought up already on public-webapps.

> 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 the response should be to redirect then the server should send the appropriate 3xx response. The case where this might want to be intercepted by script is calling other domains but this would amount to a security breech for the same reason - the server didn't specify it.

> 
> 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.
> 

Again, for forms this is outside the request\response cycle. For XHR it all sounds great.

> This is probably dangerously close to implementing state in a web document, but you can't blame a guy for trying.
> 
> Arthur Clifford
> 

Thanks,
Cameron Jones



> 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
> 
>

Received on Tuesday, 13 December 2011 18:46:11 UTC