2013-02-03 3 views
7

필자는 GET에 있던 버전 번호를 PUT 호출로 다시 전달하여 데이터베이스 테이블에 일대일 매핑하는 내 REST 리소스에 대해 낙관적 잠금을 구현했습니다. GET과 PUT을 수행 한 시간 사이에 데이터베이스에서 버전 번호가 변경되면 낙관적 인 잠금 예외가 발생했습니다. 아주 심플한 디자인.REST에서 어떻게 거친 낙관적 잠금을 구현합니까?

이제 여러 데이터베이스 테이블에 매핑되는 복합 REST 리소스에 대해 어떻게해야합니까? 여러 개의 버전 필드 (복합 리소스와 관련된 각 데이터 테이블에 하나씩)를 전달하지 않아도됩니다. 복합 자원의 단순한 예는/FooBar입니다. 여기서/Foo 및/Bar는 비 복합 자원입니다.

나는 기본적으로 파울러의 거친 그레인 잠금 패턴의 REST 구현의 예를 찾고 있어요 : http://martinfowler.com/eaaCatalog/coarseGrainedLock.html

+0

REST 서비스에서 버전을 수집하여 버전을 나타내는 고유하게 생성 된 ID가 입력되는 맵에 넣을 수 있습니까? 그런 다음 클라이언트에게 보내서 수정 한 후에 다시 보내야합니까? 그런 다음 해당 id를 사용하여 엔티티 그래프의 버전을 가져올 수 있습니다. –

답변

5

이것은 ETag header 위해 설계 된 것입니다. 이를 구현하는 가장 일반적인 방법은 응답 페이로드를 생성하고 해시를 만듭니다 (보안이 낮고 충돌이 적을 필요는 없습니다). 그런 다음 해당 해시를 ETag의 값으로 사용합니다. 이 접근 방식은 응답을 생성하는 데 사용 된 소스의 수를 모르는 것입니다.

클라이언트는 수신 된 ETagIf-Match 헤더로 다시 보냅니다.이 헤더는 서버가 요청의 최신 성을 검사하는 데 사용할 수 있습니다.

+0

그리고 "신선한"상태가 아닌 경우 HTTP 서버는 [409 (충돌) 상태 코드] (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10)를 보냅니다. –

+0

412 실제로. http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-21#section-3.1 – fumanchu

+0

흠, 흥미 롭습니다. 예를 들어, 버전 관리가 사용되고 PUT 포함 된 엔티티가 이전 (제 3 자) 요청에 의해 생성 된 것과 충돌하는 자원에 대한 변경 사항을 변경하는 경우, 409의 예제는 매우 명백합니다. 서버가 409 응답을 사용하여 요청을 완료 할 수 없음을 나타낼 수 있습니다. " –