2010-04-22 4 views
5

저는 RESTful 데이터 저장소를 구축하고 조건부 GET 및 PUT을 활용하고 있습니다. 조건부 PUT 중에 클라이언트는 이전 GET의 Etag를 자원에 포함 할 수 있으며 현재 표현이 일치하지 않으면 서버가 HTTP 상태 코드 412 (Precondition Failed)를 반환합니다. 이것은 Atom 기반 서버/프로토콜입니다.HTTP 응답 412 - 컨텐츠를 포함 할 수 있습니까?

제 질문은 412 상태를 반환 할 때 리소스의 새로운 표현을 포함 할 수 있습니까, 아니면 사용자가 새로운 GET을 발행해야합니까? HTTP 사양은 예 또는 아니오라고 말하지 않으며 Atom 사양도 아닙니다 (예제에서는 응답에 빈 엔터티 본문이 있음). 새로운 표현을 반환하지 않고 클라이언트가 명확하게 얻지 못하게하는 것은 꽤 낭비스러운 것 같습니다. 생각?

답변

2

조건부 GET 및 PUT은 '조건부 요청'으로 요약되지만 개념적으로 매우 다릅니다. 조건부 GET은 성능 최적화이며 조건부 PUT은 동시성 제어 메커니즘입니다. 함께 토론하는 것은 어렵습니다.

조건부 GET에 관한 질문 : GET을 보내고 If-None-Match 헤더를 포함하면 서버는 자원이 변경된 경우 200 Ok를 보내고 그렇지 않은 경우 304가 수정되지 않은 경우 (조건이 실패한 경우) . 412는 조건부 PUT에만 사용해야합니다.

업데이트 : 질문을 약간 잘못 읽은 것으로 보입니다. 조건부 PUT 실패시 로컬 복사본의 '새로 고침'에 관한 요점 : 캐시에 이미 최신 버전이 있고 리프레시 GET이 일부 캐시에서 제공 될 수 있습니다. 서버가 412로 현재 엔터티를 반환하도록하면 실제로 성능이 저하 될 수 있습니다.

+0

예. 초기 답변을 따르지 않고 있지만 가능한 중간 캐시에 대한 요지는 매우 좋습니다. 솔직히 내가 지금까지 본 최고의 대답. – Gandalf

3

아니요, 기술적으로는 안됩니다. 오류 코드는 일반적으로 무언가가 잘못되었다고 지정합니다. 아무 것도 콘텐츠를 반환하지 못하지만 (실제로 404와 같은 일부 오류는 찾고있는 것을 찾지 못했다는 예쁜 페이지를 반환합니다), 응답의 요지는 다른 콘텐츠를 반환하는 것이 아니라 무엇이 잘못되었는지를 알려주는 정보를 제공합니다. 기술적으로 당신은 If-None-Match : etag (당신이 통과 한 것으로 가정 함)를 통과했기 때문에 그 데이터를 반환하지 말아야합니다.

또 하나의 추가 http 호출을 최적화해야합니까?

이 문제에 대해 더 많이 생각할수록 더 나쁜 아이디어라고 확신합니다. 다른 오류가있는 콘텐츠를 반환하겠습니까? PUT 의미론은 PUT 할 수 있습니다. GET 구문은 GET에 사용해야합니다.

+0

하나의 HTTP 호출을 최적화하면 하루에 수백만 개의 저장된 요청을 쉽게 의미 할 수 있습니다. 그렇습니다. 그렇습니다.POST 의미론은 POST에 대한 것이지만 성공적인 POST에서 내용을 반환하는 것은 완전히 유효하므로 여기에 대한 귀하의 주장에 동의하지 않습니다. – Gandalf

+0

POST를 수행하지 않고 PUT을 수행하고 있습니다. POST 의미론은 두 가지 모두와 다르며 게시물에 내용을 반환하는 것은 유효합니다. 의미는 다음과 같습니다. POST 및 PUT 요청의 근본적인 차이는 이며 요청 대상의 다른 의미에 반영됩니다. POST 요청 인 의 URI는 동봉 된 엔티티를 처리 할 리소스를 식별합니다. 이 자원은 데이터 수신 프로세스이거나 다른 프로토콜에 대한 게이트웨이 이거나 주석을 허용하는 별도의 엔터티 일 수 있습니다. 이것은 POST가 URI와 무관 한 컨텐트를 반환 할 수있는 유연성을 가지고 있음을 의미합니다. – Kylar

2

업데이트 충돌로 인한 추가 요청으로 인해 성능 관련 문제가 발생할 정도로 많은 추가 요청이 발생하면 리소스의 세밀성에 문제가있을 수 있습니다.

하루에 수백만 번 여러 사용자가 같은 리소스를 동시에 편집 할 것으로 기대하십니까? 아마도 리소스를 직접 업데이트하는 대신 델타 변경 내용을 리소스에 저장해야합니다. 실제로 이러한 리소스에 대한 많은 논란이있는 경우 사용자는 오래된 데이터를 끊임없이 사용하려고하지 않습니다.

리소스에 마지막으로 수정 한 날짜와 마지막으로 수정 한 사용자가 포함되어 있고 모든 PUT 후에 GET을 수행해야하는 문제가 있다면 규칙을 왜곡해야 할 필요성을 더욱 확신하게 될 것입니다.

그러나 추가 요청의 성능 저하는 클라이언트 개발자에게 명확성을 위해 가치가 있다고 생각합니다.

관련 문제