/thumbnails API response returns "no-cache" policy, no Etag

Matt R.29

I was hoping to get clarification on the recommended approach for thumbnail caching for applications using Dropbox's REST API?

Specifically, I'm using the `/thumbnails` endpoint, but the response includes a `no-cache` policy for the `Cache-control` HTTP header. My understanding is typically this policy also includes an `Etag` HTTP header field, but one is not returned.

Perhaps the Etag isn't included because Dropbox API clients are just expected to cache the thumbnail locally, and then prior to reusing the cached thumbnail check if the file is modified using the dropbox-specific metadata (current revision, or hash etc.)

However, I'm confused why the `Cache-control` policy is `no-cache` at all and what the expected/recommended handling for thumbnails is. Can anyone clarify?

Greg-DB

Hi Matt, it sounds like you already have the right idea here. You should use the Dropbox API concepts to keep track of this, instead of HTTP caching rules. That is, you can use the "rev" value, e.g., from /metadata or /delta, to check if the contents have changed. If the rev value hasn't changed for a file, you know the contents haven't changed, and therefore your saved thumbnail for that rev is still valid. If the rev has changed, that means the file contents have changed, so you should call /thumbnails again to get the latest thumbnail.