Обновление связи «многие-ко-многим» с REST

Question

У меня есть три разные модели: User, PermissionSet и Permission. Эти модели представляют собой таблицы SQL соответственно.

User имеет ассоциацию с множеством людей PermissionSet, пользователь может иметь один PermissionSet или none. PermissionSet s будет принадлежать ни одному, ни многим. User s.

PermissionSet имеет связь «много-ко многим» с Permission s. A Permission может принадлежать нескольким PermissionSet s или none, где PermissionSet s может быть владельцем несколько Permission или ни одного.

Таким образом, я создал четыре стола: users, permission_sets, permissions и соединительную таблицу, permission_sets_permissions.

Мне нужно сохранить изменения, внесенные в User's PermissionSet. Это обрабатывается моделью PermissionSetGrant, которая имеет свою собственную таблицу, permission_set_grants.

Каков наилучший способ изменить Permission s PermissionSet с RESTful API на основе HTTP и JSON?

Например, это хороший способ изменить 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. Следовательно, пакетные операции будут выполняться во втором подходе.

Answer 1

Если вы собираетесь разрешить обновление такого большого количества разрешений на один раз, то PATCH может быть ваш друг:

Глядя на RFC 6902 (который определяет стандарт Patch), с точки зрения клиента API-интерфейс можно назвать как

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

Однако PATCH не не является idempotent метода, к сожалению (и ни один POST, для почти той же очевидной причины), поэтому путем исключения вы остаетесь с PUT, который е ine, немного более подробный, чем PATCH (клиент должен PUT весь объект, включая всю коллекцию разрешений_ид).

Answer 2

Ваше текущее решение в порядке, я думаю. Если вы хотите подключиться к разрешениям с наборами разрешений, вы можете использовать несколько идентификаторов для описания коллекций вместо использования полезной нагрузки для того же самого, например.

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/ 

Имейте в виду, что не ОТДОХНУТЬ ограничений относительно URI конструкции, так как REST operates with hyperlinks и машины клиентов. Таким образом, с точки зрения клиента не имеет значения, какая структура имеет URI, если она может быть описана с помощью шаблона URI. Единственное, что вы должны иметь в виду, что существует связь n: 1 между URI и ресурсами, поэтому несколько URI могут идентифицировать один и тот же ресурс, но один URI не может идентифицировать несколько ресурсов.