[rest-practices] Modelling membership

[Bryan Kearney]

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?

-- bk