RESTful design: using ETag and If-None-Match for fetching new items in a collection?

Question

I'm designing a RESTful web service, and trying to come up with a good way to handle caching and synchronization of collections of items. I've read about the use of Etag and If-None-Match headers for optimizing the caching of individual resources, and I'm wondering if they can be (or should be) used for collections.

I'm interested in your feedback on the following approach:

1. A collection of items is exposed at the URI http://foobar.com/items
2. A client making an initial GET request on that URI will not include an If-None-Match header. In this case, the server returns all of the items (or some amount at the server's discretion, say, the most recent N items). The response contains an Etag header indicating a "tick stamp" that represents the the current pseudo-time of the server's pseudo-clock (e.g. some counter that increases each time there is a change to the data).
3. The client caches the returned items.
4. On subsequent GET requests, the client includes the previously received Etag value in its If-None-Match header. The server checks to see if it has any items newer than the If-None-Match header, and if so, returns ONLY the newer items. Otherwise, it returns a 304 status ("not modified") and no items.

Question - am I subverting the semantic meaning of a GET by only returning the newer items in #4, rather than the whole collection (which would include items already cached on the client)? Or does this seem like a reasonable approach? Can you suggest alternative approaches that would be better?

Thanks in advance.

Answer 1

Usually, it is up to the client to do the ETAG comparison after a HEAD request, and if necessary, follow-up with a more specific request (a range request or a query for entries newer than a certain timestamp). There server should simply serve-up the requested resources.

The idea is that intermediary caching proxies can be inserted in the chain of communication without either the client or server having to change its code.