[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [rest-practices] Modelling membership



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.

	-Bob



On May 4, 2010, at 9:19 AM, Mark McLoughlin wrote:

Hey,

We're just hitting something in rhevm-api which I think is fairly
generic. So, I'll use a simple user/groups example instead of a RHEV
specific example.

A user may be a member of multiple groups. We have a top-level /users
collection and a top-level /groups collection. How do we modelling
adding a user to a group?

1) a <users> element under <group>

   One thing we didn't like about this is race conditions when editing
   the membership list using PUT - e.g. A and B see list as { bob,
   bill, bryan }, client A adds { eoghan } and client B adds { mark }.
   The result is dependent on which client posts last

   Eoghan suggests investigating whether a client could specify Etag
   in its PUT to mean "only accept the update if the current content
   matches this etag". If it fails, the client would re-GET, re-do its
   edit and re-PUT.

2) a /users/ collection under a group

   e.g. <group><link rel="users" href="/group/1234/users"/></group>

   Adding a user would be:

     POST /group/1234/users

     <user id="5678"/>

     HTTP/1.1 201 Created
     Location: /group/1234/users/5678

   We liked this because we wanted a per-group user URI. See[1]

   It also gave a nice solution to the concurrency issue above.

   We didn't like the fact that it was ambiguous whether the POST
   should create a new user or just add an existing user to the
   group's users collection.

   Also, in general, there is less expressiveness possible with
   POSTing to a collection rather than adding to a list - e.g. you
   can't order the elements in the collection with POST.

Any thoughts?

Thanks,
Mark.

[1] - this is where things get messy. Instead of "group" read "data
center" and instead of "user" read "storage domain"

A storage domain can be attach to multiple data centers. In the current
RHEV-M API, a storage domain's state is dependent on which data center
you are viewing it from

e.g. a storage domain can be "attached" in one data center and "active"
in another data center. If you query a storage domain outside of the
context of a data center its status is "mixed"

So, we're modelling that as:

 /datacenters/1111/storagedomains/5678 state = "attached"
 /datacenters/2222/storagedomains/5678 state = "active"
 /storagedomains/5678 state = "mixed"

_______________________________________________
rest-practices mailing list
rest-practices redhat com
https://www.redhat.com/mailman/listinfo/rest-practices


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]