RESTful HTTP : 동일한 URI에있는 두 명의 사용자에게 서로 다른 표현 표시

Question

하이퍼 텍스트 제약으로 하이퍼 미디어 API, 예를 들어 RESTful API를 설계하고 있습니다.

시스템의 각 사용자는 자신의 자격 증명을 사용하여 시스템에 액세스하므로 우리가 처리하는 모든 요청은 인증되고 인증됩니다. 각 사용자는 일반적으로 특정 자격 증명을 가지므로 각 컬렉션에서 다른 권한 (예 : 없음, 읽기, 읽기/쓰기)을 가질 수 있습니다.

우리는 클라이언트가 시작하는 하나의 URI, 아마도 원자 서비스 문서 또는 원자 집합의 계층 구조 (초안 원자 계층 구조 확장) 일 수 있기를 원합니다.

내 질문에 기본적으로 사용자가 같은 URI에 대해 다른 표현을보아야합니까? 아니면 사용자가 자신의 권한을 기반으로 다른 URI로 이동해야합니까?

예 : 사용자 A와 사용자 B는 시스템에서 다른 사용 권한을가집니다. 다른 자격 증명으로 동일한 시작 URI에 로그인합니다. 성공적인 응답은 다음 (2)의 하나 일 수있다 :

1. 200 OK 및 사용자 A는 동일한 URI
2. (302) (또는 다른 리디렉션)에 사용자 B보다 다른 일 예를 들면 각 사용자 본다/엔드 포인트/사용자 A (자신이 소유하는)

캐시 가능성 사이의 트레이드 오프는 자원이 클라이언트가 아니라 중개인 만 캐시되기 때문에, 물론 최소한의, 그러나 너무 가시성에 대한 트레이드 오프있다 (URI 포함 (aythenticated) 사용자 ID). 마지막으로 사용자 A (또는 수퍼 유저)가 사용자 B가 보는 것을 보도록 허용 할 미래의 가능성이 있습니다.

나는 트위터 나 페이스 북이하는 일을 묻지 않고, REST 실습가들이 이것에 관해서 이야기해야 할 것에 더 관심이있다. (200)로 회신

Answer 1

개인적으로 나는 이것을 만드는 것이 어렵다는 것을 알았고, 내용이 얼마나 달라질 지에 따라 달라집니다. 차이점이 몇 가지 추가 세부 정보가 빠진 경우 사용자별로 다를 수있는 단일 리소스로 처리 할 수 ​​있습니다.

그러나 차이점이 더 많이 나타나기 시작하면 다른 리소스를 만들 것입니다. 나는 여전히 특정 사용자에게 특정한 자원을 만들지 않으려 고 노력할 것이다. 어쩌면 특정 리소스에 대해 서로 다른 수준의 콘텐츠를 사용하여 일련의 하위 리소스를 만들 수 있습니다. 예 :

/Customer/123?accesslevel=low 
/Customer/123?accesslevel=medium 
/Customer/123?accesslevel=high 

이 방법과 함께 302가 충분할 수 있습니다. 보다 복잡한 경우 여러 개의 쿼리 문자열 매개 변수를 사용할 수 있습니다.

/Employee/123?SocialSecurityNo=yes&SalaryInfo=yes 

나는이 질문에 대한 쉬운 대답은 없다고 생각합니다.나는 대답이 가장 까다로운 REST 시나리오와 유사하다 생각 : 당신이 내 질문은 기본적으로 사용자가 서로 다른 표현을 볼 수만큼 당신이

Answer 2

옵션 1은 허용 REST 응답이며, 옵션 2

구글 데이터 API가 사용자 서비스의 상단에 괜찮은 REST 구현을 제공하고, 그들이 옵션 1을 구현하는 것보다 쉬운 많은 사용자입니다. 예를 들어 Google Calendar Data API은 http://www.google.com/calendar/feeds/default/private/full에서 HTTP GET 요청을 수행하여 사용자가 자신의 피드를 쿼리 할 수있게합니다.

Answer 3

:-) 제한 조건을 위반하지 않는 한 원하는만큼 창조적 일 수있다 솔루션 동일한 URI의 경우 또는 사용 권한에 따라 기반의 다른 URI로 사용자를 연결해야합니까?

예 : 사용자 A와 사용자 B는 시스템에서 서로 다른 사용 권한을가집니다. 다른 자격 증명으로 동일한 시작 URI에 로그인합니다. 성공적인 응답은 다음 (2)의 하나 일 수있다 :

1. 200 OK 및 사용자 A는 예를 들어 동일한 URI
2. (302) (또는 다른 리디렉션)에 각각의 사용자를 사용자 B보다 다른 것을 볼/엔드 포인트/사용자 A (자신이 소유하는 )

두 가지 방법이 편안하고있다. 자원 표현은 사용 권한에 따라 달라질 수 있습니다. 모든 요청에 ​​의해 http auth로 자격 증명 (사용자 이름, 암호)을 보내므로 통신에는 상태가 없습니다. 권한 검사 후 다른 표현 변형으로 리디렉션하는 것이 좋습니다. 그렇게하면 권한 논리를 자원 표현 논리와 완전히 분리 할 수 ​​있으므로 다른 서버로 이동하여 캐시 가능 자원 표현을 잘 작성할 수 있습니다. 예를 들어 GET /endpoint/userA으로 userA을 /endpoint/userA?owner=true으로 리디렉션 할 수 있습니다. 프로필의 소유자이거나 기능 구성을 만들 수 있습니다 : /endpoint/userA?feature1=true&feature2=false 등 ... 세밀한 액세스 제어를 설정하는 것은 매우 쉽습니다. 캐시 할 수있는 또 다른 방법은 모든 요청의 queryString에 사용자 ID를 추가하는 것이지만 리디렉션을 사용하는이 솔루션은 훨씬 깔끔합니다. 고마워요!