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.)
