First, if a user already has a resource cached in her client (browser or API client), and that resource has not changed since she cached it, she wouldn't need to wait for BatchBook to process the request and send back the response.

Second, because the load on BatchBook's servers would be lightened, I think all users would realize an immediate gain in performance, even when requesting uncached resources.

There are a couple of levels of ETag support you could provide:

1. Full Support: This would include reading an incoming "If-None-Match" header and returning a '304 Not Modified' status to the requester if the resource had not changed. This would get you the most bang, since it would cover the Web App, where most of your server resources are most likely being consumed. Currently, you're sending back a new ETag every time I request a resource, even if that resource hasn't been modified.

2. Partial Support: This would include at least sending back the correct ETag for an unchanged resource requested by the API. This would allow API clients to issue a cheap (for you and the client) HEAD request for a resource to see if the resource's ETag still matches that of a locally cached version.

Especially with the large size / complexity of some of the resources you're serving, I think it would make real sense for you to have a better caching plan that saves your server from doing unnecessary work and saves customers from having to re-download cached resources that have not changed.

Kurt