rest - 使用REST更新多对多关联

我有三种不同的模型，分别为User，PermissionSet和Permission。这些模型分别表示其SQL表。

User具有多对一关联PermissionSet，用户可能只有一个PermissionSet，或者没有。 PermissionSet可能没有或由多个User拥有。

PermissionSet与Permission有多对多关联。一个Permission可以由多个PermissionSet拥有或不拥有，其中PermissionSet可以拥有多个Permission或根本不拥有。

因此，我创建了四个表：users，permission_sets，permissions和一个联结表permission_sets_permissions。

我需要保留在User的PermissionSet中所做的更改。这由称为PermissionSetGrant的模型处理，该模型具有自己的表permission_set_grants。

在基于HTTP和JSON的情况下，使用RESTful API更改Permission的PermissionSet的最佳方法是什么？

例如，用这样的请求修改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

或使用额外的REST路径添加权限？

POST /api/v1/permission_sets/7/permissions

//  Payload
{
    "permission": 24
}

-> 201 CREATED

以及何时需要删除该权限

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

-> 203 ACCEPTED

我还要补充一点，从客户的角度来看，该请求是幂等且确定的。权限数至少为100。因此，将以第二种方法执行批处理操作。

最佳答案

我认为您目前的解决方案还可以。如果所有您想将权限与权限集连接起来，则可以使用多个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 operates with hyperlinks和计算机客户端，因此没有关于URI设计的REST约束。因此，从客户端的角度来看，只要可以使用URI模板描述URI，它的结构并不重要。您唯一需要记住的是，URI与资源之间存在n：1的关系，因此多个URI可以标识相同的资源，但是单个URI不能标识多个资源。

关于rest - 使用REST更新多对多关联，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/39558784/