2014-01-23 2 views
0

사용자 그룹이 있고 그룹에서 사용자를 추가/삭제하려고한다고 가정 해 봅시다. 내가 헷갈리는 부분은 URL을 디자인하는 가장 좋은 방법이 될 것입니다. 여기에 옵션REST 디자인 : REST를 사용하여 주어진 엔티티에서 관련 엔티티 추가/삭제

옵션 # 1

있습니다 POST/그룹/{의 groupId}/사용자 - 사용자 ID를 포함 할 요청 본문 삭제/그룹/{의 groupId}/사용자/{userId를} - - 사용자 ID 경로에있을 것입니다 및 요청 본문이 비어 있습니다

옵션 # 2

DELETE/그룹/{의 groupId}/사용자 - 요청 몸이 사용자 ID를 포함합니다,POST/그룹/{의 groupId}/사용자/{userId를} - 사용자 ID 경로에있을 것입니다 및 요청 본문이

내가 생각 비어 모두 답변은 정확하고 나는 더이 추측하지 있어요 여기에 옳고 그른 대답, 개인적 취향 만 있습니다. 그러나 널리 사용되는 것이 무엇인지 알고 싶습니다. 나는 당신이 POST ing 인 데이터가 url의 일부가되어서는 안되는 어떤 책 (이름이 나를 도피)에서 읽었 기 때문에 DELETE을 사용하는 동안 최선의 제한이 없다는 이유로 OPTION # 1을 사용 해왔다.

모든 의견을 환영합니다!

답변

0

옵션 1이 가장 일반적인 것 같습니다. 나는 옵션 2가 전혀 유효하지 않다는 느낌을 가지고 있지 않다!

+0

입력 해 주셔서 감사합니다! 요청 본문의 유일한 내용이 사용자의 ID인데도 옵션 # 1이 유효하다고 생각하십니까? – shahshi15

+0

요청 URI에 이미 'userId'가 있기 때문에 DELETE 요청을 보낼 때 요청 본문에 아무 것도 넣지 않아도됩니다. 'POST'와'PUT' 요청 만 요청 본문을 가져야합니다. –

+1

@xmenymenzmen HTTPbis 스펙에서 DELETE 요청 본문을 사용할 수 없습니다. http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#page-29 –

2

첫 번째 옵션이 가장 일반적이지만 REST에 대한 오해가 널리 퍼져 있기 때문에 아무런 의미가 없습니다. 사실상 # 1은 REST가 아니며 RPC는 순수하고 간단합니다. 생성 된 자원의 위치는 Location 응답 헤더에 리턴하거나, 최종 위치 /groups/{groupId}/users/{userId}PUT 요청을 통해 함께 컬렉션 멤버 추가

컬렉션 /groups/{groupId}/usersPOST 통해서 이루어질 수있다. POST201 Created 응답을 반환하고 PUT 또는 200 OK을 반환해야합니다 (리소스가 이미 존재하고 새 리소스로 교체 된 경우).

삭제하려면 올바른 방법은 DELETE /groups/{groupId}/users/{userId}을 사용하는 것입니다. 개인적인 취향의 문제가 아닙니다. POST은 HTTP 프로토콜로 표준화되지 않은 작업에 사용하는 방법입니다. 단순 삭제는 DELETE 방법을 통해 표준화됩니다. POST 메서드를 통해 구현하면 단순히 표준 자체에 의존하는 대신 해당 기능을 문서화해야합니다. POST은 삭제 중에 멋진 기능을 수행하는 경우에만 사용해야하며 이미 기능을 문서화해야합니다.