RESTful API에서 검색 자원에 대한 캐시 제어 정책

Question

MVC.NET을 사용하여 RESTful API를 작성하여 비즈니스 시스템에 대한 외부 액세스를 허용합니다. API에는 검색 리소스가 포함되어 있습니다. 리소스는 "/ example/search/pages/1 /? query = something"URI 형식을 취합니다.

예 : 피자를 검색하려면 "/ example/search/pages/1 /? query = pizza"URI에 액세스하면 처음 10 개의 결과가 표시됩니다. 결과의 두 번째 페이지를 얻으려면 "/ example/search/pages/2 /? query = something"등을 요청하십시오.

캐시 제어 HTTP 헤더를 사용하여 모든 리소스를 공개 캐싱 할 수있었습니다. 이 API는 API 웹 응용 프로그램을 제공하는 서버의 부하를 대폭 줄이는 데 목적이 있습니다.

그러나 검색 리소스에 사용할 캐싱 정책을 모르겠습니다. 자원 (및 그것의 URI)은 당신이 검색하는 것에 따라 다양하기 때문에, 페이지를 캐싱하는 것이 거의 없다. RESTful API에서 검색 리소스에 대해 추천하는 캐싱 정책 (예 : 캐시 제어 HTTP 헤더를 통한 캐싱)은 무엇입니까? 캐싱이 없습니까? 만료 시간이 매우 짧은 개인 캐싱? 짧은 만료를 가진 공개 캐싱?

Answer 1

적절한 최대 사용 연령을 가진 공개 캐싱이 원하는 것입니다. max-age 값은 애플리케이션에 따라 달라지며 주관적인 판단을 요구합니다.

모든 요청을 계산할 필요가 없다는 보상에 대비하여 부실 응답을 제공 할 위험을 균형있게 조정해야합니다.이 위험이 극도로 높아진다면 시간을 단축 할 수 있습니다. 원본 서버. 초기 판단이 맞는지 확인하기 위해 사용 패턴과 서버로드를 모니터링하는 것이 좋습니다.

이

는 질문의 일부가 아니었지만, 내가 당신이라면 나는 그래서, URI의 쿼리 부분에

/예/검색/페이지/1 /? 쿼리 = 뭔가

를 매김을 움직일 것입니다

이 될 것입니다 :

/예/검색 용어 = 뭔가 & 페이지 = 1

그것은 필수 아니지만 그것은 개발자를위한 직관적 것입니다, 당신은 HTML 양식을 쉽게 칠 수

?

Answer 2

대부분의 프록시는 쿼리 문자열을 사용하는 모든 것을 캐시하지 않습니다.

캐싱을 원하면 POST-Redirect-GET 패턴을 사용하여 검색 요청에 대한 새 URI를 작성하는 것이 좋습니다.

POST 검색 콘텐츠 형식 : 응용 프로그램/x-www-form-urlencoded를

용어 = 뭔가

303 페이지의 기타 위치 :/검색/일/1

이 활성화됩니다 보다 적극적으로 캐싱하지만 이러한 URI를 직접 만들어야하며 초기 POST에 의해 계속 공격을 받게됩니다. 즉, 문제가되는 쿼리 일 경우 문제를 능숙하게 해결할 수 있습니다.