Let me summarize People Restful API and the IMPLIED data model behind it.

API calls

   - /people/{uid}/all - Collection of all Public profiles for all users
   connected with uid {uid}


   - /people/{uid}/friends        -- Collection of all Public profiles
   for all users connected with user {uid} and group = "friends"
   - /people/{uid}/{groupid}      -- Collection of all people connected
   to user {uid} in group {groupid}
   - /people/{uid}/@all/{pid}      -- Public profile, returning ALL
   attributes of the user {pid} which are visible to ANY of the groups of user
   {uid}
   - /people/{uid}/@self            -- Return the COMPLETE Profile for
   user {uid}
   - /groups/{uid}/@self   -  Return ALL groups for user {uid}


Data Model (in the following, Level N+1 is inside Level N object)

   - *Level_1 * Person Object
   - *Level_2 * uid  String type
      - *Level_2 * set of all groups for this user
         - *Level_3  *groupid  (Reserved words: family, friends)
      - *Level_3 * for each group, contacts
            - *Level_4 * set of all contacts of in this group
            (set of Person objects identified by their uid)


   - *Level_2 * User profile attributes
         - *Level_3 * for each attribute, flag = public/private
         - *Level_3 * for each attribute, indicate which of the
         user's groups can view this attribute
            - *Level_4 *set of groups this attribute belongs to

what do you say?

On Wed, Apr 16, 2008 at 12:07 PM, John Panzer <[EMAIL PROTECTED]> wrote:

> On Tue, Apr 15, 2008 at 4:43 PM, Robert Evans <[EMAIL PROTECTED]> wrote:
>
> > I am trying to think of the URIs as mapping to resources on the web, and
> > trying to read it out loud. Consequently, please see the reading of URIs
> > and
> > some questions/suggestions interspersed below.
> >
> > Thanks,
> > Bob
> >
> > 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}
> >
> >
> > Sounds like: "Get people for user, {uid}; all of them."
>
>
> Yes (of course, it really just names the group of all people connected to
> user {uid}, you can do GET/PUT/POST/DELETE on this collection depending on
> what you want to do).
>
>
> >
> >
> > >
> > > /people/{uid}/friends        -- Collection of all friends of user
> {uid};
> > > subset of all
> >
> >
> >  Sounds like: "Get people for user, {uid}; only those who are friends."
>
>
> Yep.
>
>
> >
> >
> > >
> > > /people/{uid}/{groupid}      -- Collection of all people connected to
> > user
> > > {uid} in group {groupid}
> >
> >
> > Sounds like: "Get people for user, {uid}; who are also in group_id."
> >
> > That one is confusing. Won't this be the same as all people in {group
> id}?
> > I
> > have only a vague concept of "group" here, so please correct that for
> me.
>
>
> The concept here is that groups are user-relative too (see below for
> groups
> discussion).  My group "family" is much different from your group
> "family".
> friends is really exactly this type of group.
>
>
> >
> >
> >
> > >
> > > /people/{uid}/all/{pid}      -- Individual person record.
> >
> >
> > Sounds like: "Get people for user, {uid}; All of them. Only with person
> > id,
> > {pid}."
> >
> > Why not drop the 'all'? /people/{uid}/{pid}
>
>
> I only put the "all" in there to make the URLs less confusing -- anything
> at
> level 3 is always a person-id, anything at level 2 is always a group id.
> Conceptually you're saying "give me the person record as accessed through
> group 'X'".  Today people records are the same no matter what group you're
> in, but I could imagine wanting to change this (e.g., having a
> date-added-to-group field) which might vary depending on the context.
>
>
>
> >
> >
> > Then it could sound like, "Get people for user, {uid}; with person id,
> > {pid}."
> > Sounds like: "Get people for user, {uid}, with person id {pid}."
> >
> >
> > > /people/{uid}/sel            -- Self Profile record for user {uid}
> >
> >
> > Sounds like, "Get people for user, {uid}; sel."
> >
> > Why not drop the 'sel' here, and /people/{uid}/ just refers to that user
> > resource specified by {uid}.
>
>
> We could probably drop @self (we added @ signs to make meta-names not
> conflict with regular names).  Thoughts?
>
>
> >
> >
> >
> > > /groups/{uid}/self           -- Collection of groups owned by the
> > > user, which always contains 'all' and 'friends' and may contain more.
> > > (Details TBD)
> > >
> > >
> > Sounds like: "Get groups for user, {uid}; self."
> > Perhaps, predicated on the group definition, it could just be
> > /groups/{uid}
> > which gets all groups that user, {uid} belongs (owns?) to.
>
>
> The intended semantics are groups the user owns.  If we drop @self then it
> would just be /groups/{uid}
>
>
> >
> >
> > What is group ownership? Is the group any subset of people that a user
> > knows?
> >
>
> A user can in principle set up any number of groups to classify the people
> they know.  They get one special group by default, "friends".  Not
> everybody
> they know is necessarily a friend.
>
> This is different from groups-you-belong-to in principle, in that you can
> set up a group and stuff me in it without me being aware of it or caring.
> (Again, "friends" is special and has additional semantics -- it's double
> opt
> in.  Other groups may have special semantics too, but the API doesn't
> specify those semantics.)
>

Reply via email to