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

Hi Paul,

Uniform Resource Identifiers (URIs) are certainly the best choice for 
identifiers on the Web.

It appears that you want to POST a representation of a person to 
/friends in order to have the person described by the representation 
added as a friend of the currently authenticated user.

If this is correct, then I'd encourage you to:

A) describe the action you want performed with a representation (friend 
request) and POST that instead.

B) refactor things such that either:

B1) the representation at example.com/persons/1 contains a list of that 
persons friends, a list which you update by POSTing annotations (friend 
requests) to, or update by PATCHing it, or by PUTting a new representation.

B2) create a resource example.com/persons/{local-identifier}/friends 
which is a list of for each person, and again POST, PATCH or PUT to 
update it.

In all honesty though, your best bet here is most likely to take a look 
at myprofile-project.org and speak to Andrei Sambra <[email protected]> as 
they've nailed exactly what you want to do. Identification of agents 
making request, and open profiles of them are provided by WebID and 
Linked Data. This really appear to be what you need for this scenario 
(and probably all scenario's you can think of).

As a side note, you can identify who is making a request by requiring 
auth* when the person makes it, or by using the From header in the 
request (although this is rather limited as it only takes identifiers of 
the form [email protected], which then leads you down the road of needing 
WebFinger to lookup users).

Ultimately, the exact method on how you implement this depends on which 
mediatype(s) you end up using, at an abstract level it's just a simple 
three-tuple truth statement you want to send though 
"<example.com/persons/1> friend <example.com/persons/2>", via auth* you 
can find out whether it's '<example.com/persons/1>' updating their 
profile, or <example.com/persons/2> making a friend request.

Best,

Nathan



Paul Moore wrote:
> 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
> 
> 
> 
> 
> 
> 
> 
> 



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/