This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Welcome Mark - Question about caching and query parameters

 
John M Brown
Ranch Hand
Posts: 62
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mark,
Welcome to JavaRanch! I've read through your book on Safari online and had a particular question involving caching and the use of query parameters...

In the book you say
The entirety of a resource's URI should be treated opaquely by basic network-based intermediaries such as HTTP caches. Caches must not vary their behavior based on the presence or absence of a query in a given URL


I understand the specific instance sited about not ignoring requests with query parameters (i.e. not caching the results), but does this mean just cache the filtered (or paged) results in the cache and then add to the cache when other query parameters are used making it a MRU cache?

This is just a clarification, because I don't think it makes sense to return back the entire collection or store to cache and filter it before returning to the client.

Thanks,

John M Brown
Application Architect
 
Mark Masse
author and iconoclast
Greenhorn
Posts: 20
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Great question. Every character in a URI, including those present in the query part, contribute to a resource's identity (http://www.w3.org/DesignIssues/Axioms.html#canonicalization). So to me this means, in the collection pagination example, that the specific collection "page" is a distinct resource whose representations may be cached individually by their unique URIs - assuming the origin API says its okay to cache then for a bit.

My mental model for a paginated collection resource is that it is literally a "Linked List" of result pages with the "next" and "previous" link relations mirroring the classic data structure's pointer-based linkages. With the primary (non-query) URI pointing to the "head" page (resource) and the page-related query parameters identifying some subsequent page (resource) in the collection.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic