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
