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

On 2011-12-13 20:22, Cameron Heavon-Jones wrote:
>
> On 13/12/2011, at 6:32 PM, Julian Reschke wrote:
>
>> On 2011-12-13 19:17, Cameron Heavon-Jones wrote:
>>> ...
>>>>> 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?
>
> I'm not sure what the script can't do here? It can insert anything into the current document.

What I meant is that there are lots of cases where people send small 
fragments of HTML to XHR clients, and they insert those into the page. 
The right content type for those is text/html (or an XHTML type), no?

>>> 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.
>>
>
> True.
>
>
>>>>> 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.
>>
>
> Yes, sorry, i thought this is what you said some WebDAV client currently do\expect?

The WebDAV clients I know do not care about the payload. What they *do* 
care about is that the payload isn't so big that it'll start affecting 
performance. Similarly, servers probably would prefer not to send entire 
new UI pages when they know that the client won't display them anyway.

>> "Accept: text/html" means the client wants HTML. It does not indicate whether the client wants a status message or a folder UI.
>
> Yes, my approach, and i will accept it as an approach, is that these represent different resources and require unique URIs.
>
>>
>>> 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.
>>
>
> Yes, the client is defining the state of the representation through means other than resource identification - URI.

Please translate?

The client tells the server to DELETE. The server has several choices 
about what to return. It also has several choices what formats to use 
for that. These are orthogonal.

We are going in circles.

>>> 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
>
>
> I really don't think i can be accused of abusing the Accept header, if anything i hold upmost conformance. I just don't vary resource state.

I really have no idea what you refer to when you say "vary resource state".

It seems that you're missing that for methods other than GET and the 
most basic status codes, HTTP simply does not define *what* resource is 
being represented by the response. See 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-17.html#rfc.section.5.1>.

The key here is to tell the server *what* resource you're interested in 
- not the format to represent it with.

Examples:

DELETE:

- a status message, possibly anonymous (without a URI)
- a progress resource after 202 (optionally with a URI)
- nothing
- a refreshed representation of the resource that "contained" the URI 
that was deleted

These are *different* resources. They may or may not have their own URI.

Best regards, Julian

Received on Tuesday, 13 December 2011 19:37:23 UTC