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

On 13/12/2011, at 5:59 PM, Julian Reschke wrote:

> On 2011-12-13 18:48, Cameron Heavon-Jones wrote:
>> ...
>>> 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
> 
> "If no Accept header field is present, then it is assumed that the client accepts all media types." (RFC 2616, Section 14.1)

Yes, we looked at this before. Nowhere does it say what the chosen media type should be. This is an implementation choice though, and i would be more included to return a user-viewable representation like html by default.

> 
>> Accept: text\plain =>  short status message
> 
> What if the XHR client wants to embed the status message as HTML fragment into the current page?
> 

It's plain text, they can do whatever they like with a message like "Your resource has been DELETE'd".

For XHR i would be more included to return "application/json" maybe with a message, status code, app-specific info. The information can be used for whatever purpose the script requires.


>> Accept: text\html =>  representation of the collection
> 
> Again, you are overloading "Accept" with something it's not suitable for.
> 

Not so, it is perfectly acceptable and correct to return html for an "Accept: text/html". I argue that it is you who wish to do something unsuitable by returning plain text status messages in response to "Accept: text/html".

The decision being made is not *what* is being returned but how that information is rendered as a media type.  I just choose to have only 1 definition of *what*, including rendering characteristics.

>> 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 :)
> 
> No, varying on UA is MUCH worse. In particular, it doesn't work as the UA is the same for XHR and form access.
> 

Yes but it amounts to a UA abstraction. You are negotiating content based on which client, not its capabilities.

It does work with XHR and form access if the Accept header is varied.


>> 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.
> 
> OK, let's agree to disagree on this.

No problem, discussion is great.

> 
>>>> 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)?
> 
> Well, once we have a proposal that addresses these concerns.
> 
> Best regards, Julian


Yes, i agree. 

Thanks,
Cam

Received on Tuesday, 13 December 2011 21:06:16 UTC