[rest-practices] Modelling membership

[Mark McLoughlin]

On Tue, 2010-05-04 at 12:21 -0400, Bryan Kearney wrote:
> On 05/04/2010 10:15 AM, Mark McLoughlin wrote:
> > On Tue, 2010-05-04 at 09:28 -0400, Bob McWhirter wrote:
> >> 3rd resource: "membership"
> >>
> >> Sometimes called an association object.
> >>
> >> In our model, I'm sure we end up with code to pair a User to a Group.
> >> Ta-da!  Expose as REST.  Adjusting memberships now only affect the
> >> membership object you add or delete, no race conditions of updating a
> >> "list" or "roster" from either User or Group end of things.
> >>
> >> I'd probably veer towards Membership being a top-level object also,
> >> owned by neither User nor Group, but linked to from either, as a
> >> collection of pointers to the actual Membership resources.
> >
> > Nice idea, thanks
> >
> > We'll probably do this as a collection of "attachment" resources owned
> > by a storage domain - each attachment just includes a reference to a
> > data center and the status of the storage domain within that data center
> >
> > I'd prefer this approach to having it toplevel, since it means one side
> > of the relationship is implicit
> >
> 
> I like the idea, but if you make it under a top level item, doesn't this 
> degrade to /groups/{uid}/user?


By toplevel, I mean "blaa.com/memberships"

So, by not having it toplevel, what we're thinking is equivalent to:

  POST /users/1234/memberships

  <membership>
    <group id="4321"/>
  </membership>

  HTTP/1.1 200 OK
  Location: /users/1234/memberships/1111

  <membership>
    <user id="1234"/>
    <group id="4321"/>
    <link rel="self" href="/users/1234/memberships/1111"/>
  </membership>

We'll also make the membership list available read-only via the group:

  GET /groups/4321

  <group id="4321">
    <name>foo</name>
    ...
    <memberships>
      <link rel="membership" href="/users/1234/memberships/1111"/>
      ...
    </memberships>
  </group>

Cheers,
Mark.