On 06/08/2011 10:33 AM, James Bowes wrote:
On Wed, Jun 08, 2011 at 11:27:23AM -0300, Devan Goodwin wrote:
> Here is my current plan for refactoring and modelling the role to user
> and role to permission relationships as resources themselves.
>
> - Create a role with POST /roles (json blob containing not much more
> than a name) Calls UserServiceAdapter.createRole which returns a role
> with a unique ID.
>
> - Add a user to a role: POST /memberships with JSON containing just a
> username and a role ID. Calls UserServiceAdapter.createMembership()
> and returns a membership with a unique ID.
>
> - Delete a user from a role: DEL /memberships/membershipid. Calls
> UserServiceAdapter.deleteMembership().
Why isn't role memebership just a list of role ids hanging off a user?
Yeah.. why not
/users/{uuid}/roles? or /roles/users?
>
> - Add a permission to a role: POST /permissions with JSON containing
> role ID, owner key, and access type. Calls
> UserServiceAdapter.createPermission().
>
> - Delete a permission from a role: DEL /permissions/permissionId.
> Calls UserServiceAdapter.deletePermission().
>
The above two points mean that a permission cannot exist on its own,
right? it has to belong to exactly 1 role at all times. I like this.
+1
> All three objects, Roles, Permissions, and Memberships, fall into the
> category of objects we already have which should never be directly
> queried from a curator in our code base, but rather obtained through
> the UserServiceAdatper.
>
> Seem ok? I can elaborate on alternative approaches but at this point
> in time it seems like clarity and decisiveness is probably best. :)
Seems ok (except for memberships, maybe).
I think that is fine. Our default