- From: Cameron Heavon-Jones <cmhjones@gmail.com>
- Date: Tue, 13 Dec 2011 21:41:12 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: thibault <thibault@miximum.fr>, public-html-comments@w3.org
On 13/12/2011, at 8:24 PM, Julian Reschke wrote: > On 2011-12-13 21:08, Cameron Heavon-Jones wrote: >> ... >> 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. >> ... > > Now you are overloading the URI. There is only one resource here, and there's no point in assigning multiple URIs. URI overloading is almost as bad as POST method overloading :-). It's a matter of interpretation. URIs are opaque so no information should be inferred from their structure. The implementation is free to define what a request will translate into in real terms, for example if i were to DELETE ./index.html would you hypothetically expect ./index.json to still be available? If a script is provided with a URI for use in DELETE-ing a resource, that is the URI it will use - without client interpretation. This is the whole point of server-driven URIs and HATEOAS. >>>> ... >>> 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. > > The URI identifies the resource. Period. > > The preference about what information to get returned upon DELETE has absolutely nothing to do with the server's or the resource's state. Yes, we're going to get back to a loop again. If i may, with further thought i don't object to Prefer header, possibly at all. You can take this as a win if you like :) > >>>>>> 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. > > But in general, the payload returned in a DELETE response is *not* a representation of the resource identified by the URI. Actually, it's never for a succesful DELETE, because that implies that you have removed the resource. > It can be seen to be the 'final' state and representation of the resource, an ephemeral last glimpse if you will. > Neither a status message "resource deleted" nor a fresh view of a parent collection are representations of the resource you have deleted. > I don't know how you can state what a resource is and is not. They are representations of a resource, however limited or full. We are transferring representations of resources back and forth between client and server, if it is under a URI it is one of the possible representations of that resource state specific to the request representation. > >>> 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. > > No, the request URI identifies the resource you want to DELETE. Not the resource that you want to be represented by the response. Irrespective. The client should not make inferences based on URI structure. > >>> 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. > > No, no, no. These are entirely different resources. > A resource is defined as a URI not as a form of content or file. >> We have reached some degree of clarity. > > I'm not convinced about that yet. > > Best regards, Julian Yeah, that's ok i more meant we seems to be getting to the same page. This is really a very puritanical discussion... Thanks Cam
Received on Tuesday, 13 December 2011 21:41:43 UTC