다른 개발자들이 웹 캐싱과 관련하여 http://www.w3.org/DesignIssues/Axioms.html#opaque을 어떻게 조정하는지 궁금합니다. URI가 불투명하지 않다는 사실에도 불구하고 accepts 헤더에 의존하기보다는 필자가 원하는 형식 (예 : .json 또는 .xml)을 기반으로하는 레일스 접미사 리소스 요청 방식을 선호합니다.URI 불투명도 및 캐싱의 공법
동일한 문제가 XHR로 인해 해결되었습니다. 표준 HTTP 요청과 구별하기위한 쿼리 매개 변수를 추가하지 않으면 캐싱을 사용하지 않도록 설정해야합니다.
저는 URI 불투명도의 가장 순수한 해석이 실제보다 학문적 일 수 있다고 개인적으로 선택했습니다. 의견?
URI 형식은 쿼리 매개 변수가있는 요청을 기본적으로 캐시 할 수 없다는 점을 제외하면 캐시 가능성과는 아무런 관련이 없습니다. GET 요청의 캐시 가능성에 대한 모든 것은 서버 응답의 캐시 제어, 만료 및 마지막 수정 (경험적 캐시 용) 헤더에 의해 유도되며 리소스가 동적 또는 정적인지 여부와 관련이 없습니다 생성 (또는 오히려, 귀하의 브라우저는 상관 없으며 차이를 말할 수 없습니다).
URL 불투명도는 서비스가 하이퍼 미디어 기반이어야한다는 REST의 기본 원칙 중 하나를 홍보하기위한 것이며, 실제로 클라이언트는 몇 개의 잘 알려진 진입 점 URL을 "알아야"하고 어디에서나 얻을 수 있어야합니다 링크 및 양식 (또는 해당하는 API)을 탐색하여 확인하십시오.
동의 - 제가 볼 수있는 문제는 URI가 모든 경우에서 동일하기 때문에 다른 수락 헤더 (예 : HTML, XML, JSON)에 대응하는 URI를 캐시 가능하게 만듭니다. – aceofspades
사실, 사실이 아닙니다. 서버 응답에 'Vary : Accept'를 설정하여 여러 캐시 "변형"개념을 만들 수 있습니다. 실제로는 동일한 URI에 대해 여러 개의 캐시 항목을 가질 수 있으며 올바른 클라이언트 (이 경우 클라이언트의 Accept 헤더를 기반으로)에 적합한 항목을 제공 할 수 있습니다. –
URL 불투명도가 학업 성격이 아닙니다. 제 3자가 귀하의 URL에 대해 너무 많은 가정을하지 못하게합니다. 그렇게했다면 URL을 뒤집어서 URL이 Google, Yahoo, 다양한 프록시 캐시, 다양한 브라우저 등을 준수하는지 확인해야합니다. –