結論

~~まだ良くわからないがクライアント側でキャッシュできるようにしてほしい~~

追記ここから

public なデータには public の指定を
max-age はそこそこな値を 60 とか？
304の場合はRate Limitをいじらない感じ（できれば）

追記ここまで

経緯

CORSでブラウザのjavascriptから違うoriginのウェブAPIも叩けたりします。たとえば、

example.com/hoge.html

<script>
// http://example.com からでも qiita.com のAPI呼べるよ
$.getJSON("https://qiita.com/api/v2/tags/grunt/items", function(data){
  // 何かする
});
</script>

こんな感じで。CORSでどこからでも叩けるようになっているAPIというと

github API
qiita API

が有名です。なんですが、https://qiita.com/api/v2/tags/grunt/itemsのレスポンスヘッダーをみると

Cache-Control: max-age=0, private, must-revalidate

になってて、~~キャッシュが効きません~~ E-Tagベースでキャッシュが効くのですが、リクエストは飛びます。githubの場合は https://api.github.com/users/qiita に対して

Cache-Control:public, max-age=60, s-maxage=60

となっていて、ある程度キャッシュがききます。qiita.com のAPIはRate Limitが厳密に指定され（例：非認証時は同一IPで60回/時）ているのでキャッシュしやすくしてほしいかなと思います。

追記ここから

どちらも二回目以降のリクエストは304 Not Modifiedを戻していて、キャッシュは効いてました。曖昧な内容でごめんなさい。ただ、qiita.comの場合は304が戻る場合でもRate Limitが減らされるので、クライアントでキャッシュコントロールしやすいようにした方がいいのではと思いました。

github.com では以下にある通り、304戻す場合はRate Limitは減らしません。

Events are optimized for polling with the “ETag” header. If no new events have been triggered, you will see a “304 Not Modified” response, and your current rate limit will be untouched. There is also an “X-Poll-Interval” header that specifies how often (in seconds) you are allowed to poll. In times of high server load, the time may increase. Please obey the header.

https://developer.github.com/v3/activity/events/ より抜粋

追記ここまで

CORS時代のウェブAPIの行儀のよいCache-Controlとは

結論

経緯