File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Web Services and the fly likes Welcome Mark - Question about caching and query parameters Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Welcome Mark - Question about caching and query parameters" Watch "Welcome Mark - Question about caching and query parameters" New topic

Welcome Mark - Question about caching and query parameters

John M Brown
Ranch Hand

Joined: Nov 29, 2001
Posts: 62
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.


John M Brown
Application Architect

<a href="" rel="nofollow"></a>
Mark Masse
author and iconoclast

Joined: Nov 08, 2011
Posts: 20
Great question. Every character in a URI, including those present in the query part, contribute to a resource's identity ( 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.

WRML and the REST API Design Rulebook
I agree. Here's the link:
subject: Welcome Mark - Question about caching and query parameters
jQuery in Action, 3rd edition