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

Paul,

on the Web resources  are identified by URIs, so that leaves us with your
options 2 and 3. I don’t really see the problems you outline there but a
different one. What if a system assigns multiple URLs to access the same
resource but different representations thereof? For instance
example.com/persons/1.json and example.com/persons/1.xml? Both return
representations of the same resource and both would likely contain just
those URLs in the self-link. So the right link relation to use would be
canonical [1] and not self. That link can then either be embedded directly
embedded into the representations or served as an HTTP link header [2].
Using the referrer won't work as that's the page that a user agent visited
last which might has nothing to do with that resource it is POSTing.

Hope this helps,
Markus


[1] http://tools.ietf.org/html/rfc6596
[2] http://tools.ietf.org/html/rfc5988


--
Markus Lanthaler
@markuslanthaler




---------------------------------
From: [email protected] [mailto:[email protected]] On
Behalf Of Paul Moore
Sent: Friday, October 26, 2012 6:30 PM
To: [email protected]
Subject: [rest-discuss] 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