The intent with {uid} is that it's a globally unique identifier. I know
some of the earlier JS samples used "john.doe" but those weren't serious
IDs, right? The one I've seen bandied about look like
orkut.com:AF38388DEADBEEF.
The individual {pid}s don't need to be universally unique -- they could be
relative to the {uid}. Obviously globally unique {pid}s work too. I think
this could be a container decision.
On Mon, Apr 14, 2008 at 11:40 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> 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
>
