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 :-).
...
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.
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.
Neither a status message "resource deleted" nor a fresh view of a parent
collection are representations of the resource you have deleted.
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.
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.
We have reached some degree of clarity.
I'm not convinced about that yet.
Best regards, Julian
