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.
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.