2016-09-18 62 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不能標識多個資源。