It sounds to me that some of these things need further clarification in the
spec itself. Shouldn't the url format be well defined for these cases?
On Mon, Apr 14, 2008 at 10:02 PM, David Primmer <[EMAIL PROTECTED]>
wrote:
> We're struggling with these implementation details right now. I'd love
> to see what others have decided on.
>
> quick summary of the proposed url system (just for the people api)
>
> /people/{uid}/all -- Collection of all people connected to user
> {uid}
> /people/{uid}/friends -- Collection of all friends of user
> {uid}; subset of all
> /people/{uid}/{groupid} -- Collection of all people connected to
> user {uid} in group {groupid}
> /people/{uid}/all/{pid} -- Individual person record.
> /people/{uid}/sel -- Self Profile record for user {uid}
> /groups/{uid}/self -- Collection of groups owned by the
> user, which always contains 'all' and 'friends' and may contain more.
> (Details TBD)
>
>
> We're expressing the friend graph in some of these queries but It's
> not clear from the spec how to resolve {uid} and {pid}, especially if
> they may actually be in the same underlying person data table. In the
> sample file state-basicfriendlist.xml, the user's ID's are simple
> firstname.lastname and relations to friends are through this primary
> key and the data set is self-referential.
>
> contrary to this simple data set, we should assume that there will be
> some hidden primary key in the account/user data we're exposing and
> that the public name someone refers to is translated to something else
> by the service's backend. For example, your userid may be 'john.doe'
> at some social network, but the primary key on your user record in
> their database will be some other form of GUID that you never see like
> "john.doe.xyz123" in that system.
>
> "/people/{uid}/self" is the simplest pattern above but even it raises
> a lot of questions. It is the profile of the user -- uid in this case
> is the user of the application. I'll use gmail as an example system.
> "uid" here is a gmail account, [EMAIL PROTECTED] (what does the
> actual url string look like?
> "http://host.com/social-api/people/john.doe/self"; ? ). The profile is
> the profile info that the user has recorded for that account. I'm
> assuming the 'view' of this data is the full projection and the api
> would allow them to edit it.
>
> Under the covers, the john.doe user name or profile name needs to map
> to a GUID in the container's auth system. And, the request will come
> with an auth an "x-oauth-os-uid" header or parameter that includes a
> link to the GUID of the user with right to act as that user. (may be
> an admin account that can act on behalf of that user). In this
> scenario, it seems that even if we have a GUID for the authorization,
> we still need to be able to deterministically look up "john.doe" in
> the backend. Or, is it true that {uid} above can be very loose as the
> actual identity of the user of the app will come from the auth
> context?
>
> And just to dip my toe in the grammar of the urls,
> /people/{uid}/all/{pid}, which is an individual person record who is
> associated with {uid}. I'd assume that in a situation where the url is
> "http://host.com/social-api/people/john.doe/all/john.doe";, we'd be
> looking up "john.doe" (the one on the left side of the "all") first as
> a primary user of the container and then looking in the collection of
> contacts for john.doe That could include someone named "john.doe" but
> not not a full member of that particular container (the difference
> between being a gmail user and that gmail user having a contact who
> happens to be named the same as them or have their email address). In
> this case, we're not actually going into the friend graph of the local
> system but into the private contact storage of the user. (I believe
> Plaxo has this sort of distinction). The rules would change if we were
> on a closed system where you could only 'friend' someone in the system
> that had a uid. In that case the people/john.doe/all/john.doe wold be
> illegal. I guess the meaning of these relations isn't clear to me, nor
> is how much of this shindig needs to codify.
>
> davep
>
--
~Kevin
