3

User, PermissionSetPermission의 세 가지 모델이 있습니다. 이 모델은 각각 SQL 테이블을 나타냅니다.REST와 다 대 다 연관 업데이트

User은 many-to-one 연관이 PermissionSet이고, 사용자는 PermissionSet 또는 none을 가질 수 있습니다. PermissionSet은 none 또는 many User에 의해 소유됩니다.

PermissionSetPermission과 다 대다 연관이 있습니다. Permission은 복수 PermissionSet 또는 없음으로 소유 할 수 있습니다. PermissionSet은 복수 Permission을 소유하거나 전혀 소유하지 않을 수 있습니다.

이렇게 4 개의 테이블을 만들었습니다 : users, permission_sets, permissions 및 접합 테이블 permission_sets_permissions.

변경 사항을 UserPermissionSet에서 유지해야합니다. 이 모델은 PermissionSetGrant이라는 모델로 처리되며 자체 표가 permission_set_grants입니다.

PermissionSetPermission을 HTTP 및 JSON을 기반으로 RESTful API로 변경하는 가장 좋은 방법은 무엇입니까?

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 경로와 권한을 추가 :

예를 들어, 같은 요청으로 PermissionSet을 수정할 수있는 좋은 방법입니다?

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는 불행하게도 idempotent 방법하지 않습니다 (그리고 어느 쪽도 거의 같은 명백한 이유를 위해, POST입니다) 배제에 의해 당신이 PUT 왼쪽하고, 그래서, 그러나

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

처럼 호출 할 수 에프 ine, PATCH보다 약간 자세한 정보가 표시됩니다 (클라이언트는 permission_ids의 전체 모음을 포함하여 PUT 전체 객체를 가지고 있습니다).

1

현재 해결책은 괜찮습니다. 권한 세트로 권한을 연결하려는 경우 여러 ID를 사용하여 동일한 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 만 여러 리소스를 식별 할 수는 없다는 점을 명심해야합니다.