REST: Deleting non-canonical resources - rest

Question

If /users/{username} is an alias of /users/{userId} (one cannot exist without the other) then I am expecting that deleting the former means that you want to delete the latter.
If /lists/{listId}/users/{userId} is an reference to /users/{userId} (one can exist without the other) then I'm expecting to be able to delete the reference without affecting the canonical resource.
In both cases, invoking HTTP GET will result in HTTP 303 to the canonical resource.
I believe that it is confusing that both types behave the same for HTTP GET but not for HTTP DELETE.
This has led me to the following questions:
What should happen when HTTP DELETE is invoked on an alias?
What is the appropriate way to remove references from a list without removing the actual object they point to?

Answer 1

5.3.5. DELETE
The DELETE method requests that the origin server delete the target
resource. This method MAY be overridden by human intervention (or
other means) on the origin server. The client cannot be guaranteed
that the operation has been carried out, even if the status code
returned from the origin server indicates that the action has been
completed successfully. However, the server SHOULD NOT indicate
success unless, at the time the response is given, it intends to
delete the resource or move it to an inaccessible location.
**> A successful response SHOULD be 200 (OK) if the response includes a
representation describing the status, 202 (Accepted) if the action has
not yet been enacted, or 204 (No Content) if the action has been
enacted but the response does not include a representation.**
So:
If /users/{username} is an alias of /users/{userId} (one cannot exist without the other)
then > I am expecting that deleting the former means that you want to delete the latter
What should happen when HTTP DELETE is invoked on an alias?
"both" resources must to be deleted. as i understand if one can not exist without other they are just different identifiers of same resource, so after deleting one of them following requests must be answered with 404 Not Found for both.
What is the appropriate way to remove references from a list without removing the actual object they point to?
UPDATE:
My question is what HTTP methods should be used to indicate that a client would like to remove references from a list?
If user(client?) would like to remove reference from a list without removing actual resource there is only one way - client must send PUT request with modified list to the server which means that existing list must be replaced with a new one. If user doesn't have enough permissions "403 Forbidden" can be returned in response.
To do the reverse of this(i.e. inform user when list was changed) if resource(i.e. list in this case) is supposed to be cached on client side and removal of some other resource affects this list, only approach i can think to "inform" user is to use caches. For example:
REQUEST
GET /list HTTP/1.1
Host: service.org
RESPONSE
HTTP/1.1 200 OK
Content-Type: application/...
Content-Length: ...
Cache-Control: private, max-age=0
ETag: a32lasdf
In the response above Cache-Control header value "private, max-age=0" is an instruction for client that it can cache representation locally though must send following request to the server each time:
REQUEST
GET /list HTTP/1.1
Host: service.org
If-None-Match: a32lasdf
if /list resource is untouched then ETag value will match "If-None-Match" value, server can respond with "304 Not Modified" and client doesn't need to do anything. But if previous removal action affected the /list, hash code for ETag will be different from one which is provided with "If-None-Match" header and thus new representation of the /list resource will be returned by server.

Answer 2

URIs are references to resources, not the resources themselves. In a sense, they are all canonical. Different URIs may identify the same resource. They may also be pleceholders for something that doesn't even exist yet. The "one cannot exist without the other" concept is something specific to the application, it's not a REST constraint. Ideally, you won't have URIs depending on each other. If you delete the resource all URIs pointing to it will point to nothing. Or at least that's how things should be if the URIs were pointing to resources and not to one another.
UPDATE:
According to RFC2396:
1.1 Overview of URI:
...
Resource
A resource can be anything that has identity. Familiar
examples include an electronic document, an image, a service
(e.g., "today's weather report for Los Angeles"), and a
collection of other resources. Not all resources are network
"retrievable"; e.g., human beings, corporations, and bound
books in a library can also be considered resources.
The resource is the conceptual mapping to an entity or set of
entities, not necessarily the entity which corresponds to that
mapping at any particular instance in time. Thus, a resource
can remain constant even when its content---the entities to
which it currently corresponds---changes over time, provided
that the conceptual mapping is not changed in the process.
Identifier
An identifier is an object that can act as a reference to
something that has identity. In the case of URI, the object is
a sequence of characters with a restricted syntax.
UPDATE:
I guess, if the resource is accessible/modifiable through multiple URIs, it's up to the application to designate a canonical one (the URI that is going to be included in the hypertext of responses). But yes, it's the URIs that are non-canonical (from the application's point of view), not the resources.