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
