서버 측 세션이 REST를 위반합니까?

14

에 따르면 로이 필딩 그의 독창적 인 논문에서합니다 (HTTP 사양의 원리 저자 중 한) 건축 스타일 때 REST을 논의 , 그가 언급 :

[E] 클라이언트에서 서버로의 각 요청은 요청을 이해하는 데 필요한 모든 정보를 포함해야하며 서버에 저장된 컨텍스트를 이용할 수 없습니다.

"저장된 컨텍스트"는 응용 프로그램 상태, 예를 들어 다음 페이지의 페이지 번호가 자원 상태, 예를 들어 모든 데이터 저장소, 이미지 등-REST의 전체 지점 인 응용 프로그램 상태를 참조합니다 .

순수한 휴식을 위한 대부분의 시도 (위의 논문을 따르는 구현으로 정의 됨)는 서버 에 세션 데이터를 저장하는 것에 대한 의존성 (지속적이든 아니든) 으로 인해 실패해야 한다고 말하는 것이 공정한가 ?

세션의 개념은 특히 웹 개발자에게 공통적이지만 위의 정의에 따라 RESTful입니까?

rest

— 매트
소스

2

나는 그 정의에 따르면 실제로 아무 것도 편안하지 않다고 말하지만 그 정의는 어떻게 합리적으로 논리적입니까? '휴식'Google 검색-Google 검색 요청에서 인터넷 색인을 제공해야한다고 가정 해보십시오. 뭐? 아니요, 지속성 저장소를 가질 수없고 편안하다고 말하는 것은 편안한 인터페이스가 실제로 의미가 없다고 말하는 데 중요합니다. 그것은 우리가 모든 메모리 세션을 유지하고 ... 여전히 좋은 휴식 설계의 말을 시작해야 의미하지 않는다

— 지미 호파

3

응용 프로그램 상태 와 리소스 상태 가 구별된다는 점에 주목해야한다고 생각합니다 (Google 색인은 리소스 상태이며 완벽하게 합법적입니다). 질문에서 더 명확하게해야합니다.

— Matt

그런 구별이 있습니까? 정의하십시오. :) 사람들이 이전에 이것을 정의하려고 시도하는 것을 보았지만 실제로 다르지 않기 때문에 실제로 퍼지됩니다. 둘 다 변경 가능한 데이터이며, 한 상태와 다른 상태의 유일한 관련 차이점은 지속적인지 아닌지에 대한 것입니다. not 형식은 일반적으로 재생 가능한 것을 의미합니다.

— Jimmy Hoffa

1

나는 이것을 스스로 궁금해했다. 아무도 왜 내 응용 프로그램이 금 "휴식"스타를 원해야하는지 설명하지 않았으므로 걱정하지 않아도됩니다.

— psr

10

예, 세션 상태는 RESTful 앱을 비 RESTTful로 만듭니다. 사소한 예, 내 동생은 월스트리트 저널에 가입합니다. 그녀는 정기적으로 페이 월 뒤에서 무언가를 읽고 WSJ 계정이없는 친구에게 (WSJ가 아닌 자신의 이메일 클라이언트를 통해) 링크를 보내려고합니다. 클릭, 전송, 실패 그 URL에 대한 언니의 경험은 분명히 그녀의 친구의 경험과 다릅니다.

관련이 있지만 주제에 국한되지는 않음 : 나는 인터넷에서 상당한 연구 노력을 지원하도록 설계된 응용 프로그램의 초기 설계 단계에 있습니다 ( 퀘스트 (생각 : 스테로이드 및 LSD에 대한 책갈피)라고 함). 퀘스트의 소유자는 자신의 데이터에 대한 특정 뷰를 다른 사람과 공유하려고하지만이 뷰에는 UI 상태 (예 : 어떤 패널에 어떤 데이터가 어떤 창에 표시되는지 시각화)와 UI에 액세스하기위한 적절한 권한의 조합이 필요합니다 데이터가 표시됩니다. 수신자가 의도 한보기를 얻는 데 필요한 저장 상태가 많이 있습니다.

나의 현재 솔루션은 별도의 객체 뷰에 필요한 UI / ACL / 어떤 정보를 모두 저장하기위한 URL (아마 UUID을)를 호출하는 것입니다 그 객체입니다. 나는 뷰 객체에 액세스하는 것이 그것을 가지고있는 모든 사람이 동일한 정보 / 경험을 얻는다는 의미에서 RESTful로 간주 될 수 있다고 생각합니다.

— 피터 로웰
소스

1

당신은 객체 예제를 볼 수 있습니다 . 산뜻한.

— Matt

다른 위대한 대답에도 불구하고 이것을 대답으로 받아들이는 것은 주로 질문에 직접 대답하고 매우 명확한 예를 제공하기 때문입니다. 또한 뷰 객체 의 두 번째 부분 이 스케일을 기울였습니다.

— Matt

1

wsj 사이트가 안전하지 않은 응용 프로그램의 예라고 말하면 귀하의 예가 그것을 보여주는 것에 동의하지 않습니다. WSJ 사이트가 예를 들어 자매의 클라이언트가 데이터를 제공하기 위해 완전히 제공 한 데이터에 의존하는 경우 @Matt가 정의한 RESTful 정의에 의해 결정됩니다. 그러나 임시 메모리 내 세션 상태에 의존하는 경우 Matt은 RESTful하지 않은 정의에의합니다. Matt가 제공 한 정의는 구현 세부 사항을 기반으로하고 REST는 소비 기술에 의해 더 잘 정의되므로이 점을 지적합니다.

— Jimmy Hoffa

@JimmyHoffa- REST 제약 조건에 대한 나의 이해 는 상태 가 없다는 것입니다 . 그것은 나에게 명백한 것처럼 보인다.

— 피터 로웰

WSJ 애플리케이션에 상태가 없으면 클라이언트가 볼 수있는 기사를 보내야합니다. 이 기사는 사이트 관리자가 언제든지 편집 할 수 있으며 WSJ 앱 상태의 한 부분 인 실수는 없습니다. 나는 그것이 지속되는 상태 라는 점에서 구별되는 점이라고 생각 합니다. 따라서 세션과 같은 불완전한 상태보다 더 많은 보증과 관리 오버 헤드가 있으며 트랜잭션의 원 자성 제어가 더 간단 할 것입니다. 이것은 간단한 소비 모델과 함께 사람들이 휴식을 원하는 것입니다. (제 생각에는)

— Jimmy Hoffa

2

서버 측 세션이 REST를 위반합니까?

그들은 확실히한다! REST를 구현할 때 서버 측 세션이 없어야합니다. 그렇지 않으면 하이브리드 RPC / REST 솔루션이 있습니다.

클라이언트는 새로운 요청이있을 때마다 클라이언트를 인증하는 데 필요한 정보를 포함하여 요청을 서비스하는 데 필요한 모든 컨텍스트를 RESTful 서비스로 보내야합니다. 서버는 후속 요청을 더 빨리 처리하기 위해 정보를 자유롭게 캐시 할 수 있지만 캐시 된 정보는 서버 측 세션에 해당해서는 안됩니다. 즉, 요청 자체에는 캐시 된 상태가없는 경우에도 처리하기에 충분한 정보가 포함되어야합니다.

— Dasblinkenlight
소스

1

아마도 "세션 데이터"의 의미에 따라 달라질 수 있습니다. 정확한 용어입니까?

두 당사자 간의 보안 통신에는 종종 클라이언트가 권한 부여 방식으로 각 요청에 제공해야하는 시간 제한 "액세스 토큰"을 생성하고 저장하기 위해 서버가 포함됩니다. 이 액세스 토큰은 이미 "세션 데이터"라고합니다. 서버 측에 시간이 제한되어 있으며 한 클라이언트와 관련이 있습니다 (보통 그의 권한).

이런 종류의 작업이 비 RESTful으로 표시되어 있으면 매우 놀랍습니다. OAuth가 예입니다.

나는 전문가가 아니며 여기에 확신이 없습니다. 도움이되기를 바라는 통찰력을 공유하고 있습니다.

— 코스
소스

1

REST의 가장 중요한 점은 자원에 대한 URI가 항상 동일한 자원을 가리키는 것입니다. 따라서 사용자는이 리소스에 대한 참조를 전달할 수 있으며 모든 사람이 동일한 것을 보게됩니다. 이것을 REST (Representational State Transfer)라고합니다. 서버가 상태를 유지하고 동일한 URI에 대해 다른 리소스를 제공하면 더 이상 순수한 REST가 아니라고 말할 수 있습니다.

— 퍽
소스

사용자가 똑같은 것을 보게되는 것은 아닙니다. 액세스는 어느 사용자가 볼 수있는 정도를 지시 할 수 있습니다.

— Erik

@Erik 그러나 사용자는 요청에서보고 싶어하는 양 (Accept 헤더 사용 포함)을 명시하므로 Puckl의 답변은 사실입니다.

— Johan

1

@Johan 나는 동일한 엔드 포인트에서 다른 사용자에 대해 다른 데이터를 반환합니다. 그렇지 않으면 사용자 인증의 요점은 무엇입니까?

— Erik

@ 에릭 나도 그렇게 할 것입니다. 아무도 인증이 리소스 상태를 벗어난 것으로 생각하기 때문에 뷰가 인증 된 사용자의 영향을받는 경우 엄격히 말하면 더 이상 RESTful하지 않습니다. RESTful 배지를 원할 경우 액세스를 요청한 사람에 따라 리소스에 대한 여러 "보기"를 작성해야하며 일부보기에 대한 액세스 권한 만 부여합니다. 따라서 public은 / userprofiles / {userID} / publicview에 액세스 할 수 있고 사용자는 / userprofiles / {userID} / fullprofile에 액세스 할 수 있으며 승인 된 친구는 / userprofiles / {userID} / friendsview에 액세스 할 수 있습니다

— Johan

0

세션은 기본적으로 상태 비 저장, RESTful 애플리케이션에 상태를 추가하는 데 사용됩니다. 따라서 공식적으로 RESTful 응용 프로그램의 상태를 유지하지만 서버 유지 상태를 유지하면 각 요청 / 응답마다 모든 데이터를 앞뒤로 전달할 필요가 없으므로 수명이 조금 더 쉽습니다 .

세션 (보다 일반적으로는 상태)을 사용하면이를 피할 수 있으며 성능 (데이터 전송이 적음) 및 보안 (변조가 가능한 데이터가 적음)에 긍정적 인 이점이 있습니다.

따라서 공식적으로 REST 정의의 일부를 위반하지만 세션을 통해 상태를 사용 하지 않는 RESTful 애플리케이션은 거의 볼 수 없습니다 .

— 올렉시
소스

동의하지 않습니다. 브랜드, 색상 및 크기별로 필터링 할 수있는 쇼핑 사이트가 있습니다. 기존의 Web 1.0 웹 사이트에서는 일부 확인란, 서버 측 세션 및 POST를 통해이를 처리 할 수있었습니다. example.org/shirts에 대한 링크를 공유하려면 사람들이 내가 중간, 검은 색 및 뿌리를 선택한 것을 볼 수 없습니다. (이것은 또한 다시 클릭 할 때 추악한 "데이터를 다시 저장하고 있습니다"라는 메시지를 발생시킵니다.) 그러나 example.org/shirts/medium-black-roots에 대한 링크를 공유하면 모든 사람이 동일한 표현을 갖습니다. 필요한 모든 상태 정보는 URL (필요한 경우 POST 본문이지만 공유 할 수는 없음)에 있습니다.

— Jesse Buchanan

... RESTful은 모든 것에 적합하지 않을 수 있습니다. 귀하의 가상 응용 프로그램 자원이 지향적입니까 (쇼핑 사이트는 확실합니다!)? 아마도 리소스 지향적이지 않은 상태가 많은 RIA에는 적합하지 않을 수 있습니다. 솔직히 좋은 예를 생각할 수 없습니다.

— Jesse Buchanan

0

이 문장의 의미는 REST API를 호스팅하는 응용 프로그램 서버가 일종의 배후 메커니즘에 의한 요청과 주변 상태를 연결하지 않는다는 것입니다. 어플 리케이션 서버 와 데이터베이스 서버 의 차이점을 고려하십시오 . REST 제약 조건은 응용 프로그램 서버가 상태 비 저장 상태 여야한다는 것 입니다. 그러나 애플리케이션 서버는 권한 헤더 또는 Uri 자체 의 사용자 / 암호 조합과 같이 요청의 일부인 정보를 기반으로 자원 상태에 대한 요청을 데이터베이스 서버에 위임 할 수 있습니다. 결국 REST는 클라이언트 / 서버 모델을 기반으로합니다.

— 오일러
소스