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

On 13/12/2011, at 7:36 PM, Julian Reschke wrote:

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

Yes, i understand what you mean here. It is reasonable though that these *may* be thought of\implemented as different resources, ie:

http://www.example.com/index.html

http://www.example.com/index.html?fragment=true

Deleteing the first results in a full response, deleteing the second is a fragmented response from a fragmented version of the resource. 


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

Yes, i understand the use case and that some may prefer to implement using headers. 

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

As described above, the state is defined through URI. The server doesn't have a choice as there is only 1 state the resource is in.

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

By changing the content of the representation you have transferred a different state of the resource.

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

Yes, by URI - the Uniform Resource Identifier.

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


Possibly reframe as a single resource being returned in multiple forms of representation. In this regard they are all the same resource being represented according to client capability. The state is identified only by URI.

We have reached some degree of clarity.

Thanks,
Cam

Received on Tuesday, 13 December 2011 20:09:07 UTC