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

Paul Moore wrote:
> Nathan,
> 
> Firstly, thanks for the response.
> 
> I've taken a look at the myprofile-project.org and it looks promising.  From what I can deduce it's based on the FOAF work, which in turn is built on RDF.  As we're currently a bit of a JSON shop, it's somewhat tricky to directly translate this, but I'll pick this up with Andrei directly.

JSON-LD can help you there, or the JSON encoding of microformats :)

> I think your Option A is the most palatable, as frankly instead of a "friend-request" representation, this can just be a "friend" representation which then links to a person.  This nicely separates the relationship semantic from the entity semantic, and thus (as with all 'resource-parititioning") the cache concerns can be independently handled / optimised.

Exactly.

> I'm still somewhat sceptical of the use of the "self link" as in most cases (all cases for my current usage) it's just a restatement of the Request-URI (or redirection thereof), but, the separate representation simplifies the problem.  Perhaps I had over-collapsed the representation design and just needed to back-away a little.

It does have it's uses, especially rel="canonical" for several 
similar/identical resources.

However, it's also useful to consider the messages, and look to those. 
After all you can model the state of a resource within a protocol as a 
function of all the messages to date - or -  the current state (Sn) as a 
function of a message M and a previous state (Sn-1), and time T. That is 
to say, it's the messages which change the state of a resource. So any 
resource which changes it's state by way of messages, would do well to 
consider those messages, especially the effective-request-URI for the 
resource currently being interacted with / requested. I know HTTP is 
often "black-boxed" by components to hide the implementation details 
(especially request lines and headers), but they're pretty vital to 
building RESTful services!

Best,

Nathan

> Anyway, thanks for the thinking.
> 
> Best regards
> 
> Paul
> 
> 
> On 27 Oct 2012, at 14:34, Nathan wrote:
> 
>> 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 [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
> 
>