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

On 2011-12-13 19:17, Cameron Heavon-Jones wrote:
> ...
>> "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.

Yes. It means the client didn't say, not that it doesn't want anything.

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

What if the message is supposed to contain HTML?

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

Yes, that's one thing that can be done, but not the only one.

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

I didn't say that, you claimed I did.

"Accept: text/html" means the client wants HTML. It does not indicate 
whether the client wants a status message or a folder UI.

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

Nope. It's negotiation on the client's expectation. The same client can 
have different expectations depending on what's going on.

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

It may work in *some* cases by abusing the Accept header.

 > ...

Best regards, Julian

Received on Tuesday, 13 December 2011 18:32:55 UTC