ETags are kind of awesome. We should consider using them for our API endpoints. Would be nice to use with Fireplace.

See also: bug 845967.

This bug isn't possible due to user-specific data in the API's output.

Depends upon the API.

None of the fireplace endpoints would find any benefit from this. And plus, we don't (and won't) cache full API responses across sessions.

I think this could become potentially very valuable as we add more APIs that update resources. If the ETag headers differ we know the resource has changed since loading it.

Agreed we still need it, removed fireplace blocker.

Thanks to bug 946845 we'll have ETags in some specific circumstances (at the time I'm writing this comment, with the latest iteration, it's only when there is a 'cache' parameter in the query string, if it's a GET request and the status is 200). However, this bug shouldn't be closed, because we'll want ETags more specific than the ones django provides, so that we're able to a) answer If-None-Match faster inside API code b) use ETags to avoid conflicts when doing PUT/PATCH c) have them in every situation.

Actually correction: We are always setting ETags regardless, by setting django's `USE_ETAGS`: https://github.com/mozilla/zamboni/blob/master/mkt/settings.py#L325-L326

Based on last comment.