The missing cache control allows the response to be cached for a longer period of time
than we probably want.

Because all writes to the tracker via REST must include an ETag, there shouldn't be any
cases of lost edits. But users might have their edits rejected if they get a stale response.

Also we need different lifetimes for different levels of the REST hierarchy.

For example non-issue levels: /rest, /rest/data can probably be cached for a while.

/rest/data/issue should probably have the same cache headers as for an index page.

/rest/data/issue/1 or /rest/data/issue/1/title have the same cache headers as an item page.

/rest/data/roles are probably the same as /rest since it won't change without a
server restart.