How to identify existing resource in a POST(a) request

Hi all,

I'm currently wrangling with a problem about identification of existing resources within the representation of a POST request.

To make this more tangible, lets consider that:

(i) there are resources at the following URI's that represent person-like things

	example.com/persons/1
	example.com/persons/2
	graph.facebook.com/2

(ii) and that my user-agent has cached them, 
(iii) and that I am authoritative for example.com:

Let's also add that there is a collection at "example.com/friends" which with a GET request returns a list of (links to) persons that have been classified as friends.

The /friends collection resource accepts POST, and interprets the representation as 'someone to add to my friends' i.e. a reasonably standard implementation of POST(a) for a collection.

Option 1:  Use a domain specific identifier

If I consider only the local domain (ignoring the externals for a moment) then using an attribute such as 'id' (or similar) seems reasonable for identification of the resource.  For example, the representation indicates an 'id' of 2, then I could *infer* that the intent is to add "example.com/persons/2" as a friend.  The issues here are that either:

i) only a subset of resources must be POSTed to the /friends collection (i.e. person like things), or
ii) a non-overlapping identifier has to be used (i.e. nothing else in the domain can have an 'id' of 2.  

Whilst implementation of UUIDs (or similar) would work around the uniqueness of identifier point (ii), it cannot be guaranteed that only a subset of (person like) resources will be sent to the server (always the client's intent).

Further, when we introduce external domains, even the UUID solution is inadequate (i.e. is it an example.com identifier or a facebook.com identifier?) as the domain is not known.

So, I think this slightly clumsy derivation concludes with the answer, use the URI - it is after all the global identifier.

Note: whilst this appears obvious, compare with *all* the 'id' based solutions in the wild - I suspect that 'id' based solutions will remain limited to local domain solutions rather than embracing the distributed aspects of REST.

Option 2: Use the URI in the representation

The typical / established approach for representations to identify their resource is through a "self link".  This is variability encoded as a link with a "rel" of "self" (IANA link relation), or just as a property of a attribute e.g. link => uri... or self => uri...  Irrespective of the encoding, what we are mandating here is that the representation has a "self" identifier in it, and that identifier is a URI.

Option 3: Use the URI in the Request headers...

Mandating that such a self link is encoded in the representation seems somewhat onerous on media type designers, and ripe for disagreement.  I was therefore wondering if any standardised HTTP Request headers could help here?

The 'Referer' header appears to offer hope:

"The Referer[sic] request-header field allows the client to specify, for the server’s benefit, the address (URI) of the resource from which the Request-URI was obtained allows the client to specify, for the server’s benefit, the address (URI) of the resource from which the Request-URI was obtained" [RFC2616]

However, I've not seen or heard about this header being used in this manner.  Does anybody know of any research in this space?

Any thoughts on Options 2 or 3?

Thanks in advance

Paul