2016-09-18 63 views
3

我有三种不同的型号,分别为User,PermissionSetPermission。这些模型分别代表它们的SQL表。更新与REST的多对多关联

User具有多对一关联PermissionSet,用户可能有一个PermissionSet或没有。 PermissionSet s将归无或多个User s所有。

PermissionSetPermission s有多对多关联。 A Permission可能拥有多个PermissionSet或没有,其中PermissionSet可能拥有多个Permission或根本没有。

所以我创建了四个表格:users,permission_sets,permissions和联结表,permission_sets_permissions

我需要坚持在UserPermissionSet中所做的更改。这是由一个名为PermissionSetGrant的模型处理的,该模型具有自己的表格permission_set_grants

根据HTTP和JSON,使用RESTful API更改PermissionSetPermission的最佳方法是什么?

例如,它是一个很好的方式来修改PermissionSet有这样的要求:

PUT /api/v1/permission_sets/7 

// Payload 
{ 
    "permission_set": { 
     // Assume these properties of the entity aren't changed 
     "name": "default", 
     "description": "Default permission set.", 

     // Here we're changing the permissions 
     "permission_ids": [ 
      24, 
      27, 
      35 
     ] 
    } 
} 

-> 200 OK 

或有额外的休息路径,而不是添加权限?

POST /api/v1/permission_sets/7/permissions 

// Payload 
{ 
    "permission": 24 
} 

-> 201 CREATED 

,当我们需要删除权限

DELETE /api/v1/permission_sets/7/permissions/24 

-> 203 ACCEPTED 

我还想补充一点,请求来自客户端的方面幂和确定性。至少,权限数量为100。因此,批处理操作将以第二种方式执行。

回答

0

如果你要允许这样的大量立刻权限的更新,然后PATCH可能是您的朋友:

RFC 6902展望(定义修补程序标准),从客户的角度来看,该API可以被称为像

PATCH /api/v1/permission_sets/7 
[ 
    { "op": "add", "path": "/permission_ids", "value": [ "24", "27", "35" ]} 
] 

然而,PATCH不是idempotent方法很不幸(既不是POST,对于几乎相同的原因很明显),因此受到排斥留给你的PUT,这是F ine,仅比PATCH(客户端已经对PUT整个对象,包括permission_ids的整个集合)更详细一些。

1

我认为您目前的解决方案没问题。如果您想要使用权限集连接权限,则可以使用多个ID来描述集合,而不是使用相同的有效内容(例如,

PUT /api/v1/permission_sets/1+2+3/permissions/4+5+6/ 
DELETE /api/v1/permission_sets/1+2+3/permissions/4+5+6/ 

如果我是你,我不会被等级URI设计卡住,这在大多数时间是不方便的。

PUT /api/v1/permissions/4+5+6/into/permission/sets/1+2+3/ 
DELETE /api/v1/permissions/4+5+6/from/permission/sets/1+2+3/ 

知道,有没有REST约束有关URI的设计,因为REST operates with hyperlinks和机器的客户。所以从客户的角度来看,只要URI可以用URI模板来描述,URI的结构并不重要。唯一需要注意的是,URI和资源之间存在n:1关系,因此多个URI可以标识相同的资源,但单个URI不能标识多个资源。