Кэширование вызовов API Github - программирование

У меня есть общий вопрос, связанный с кэшированием вызовов API, в этом случае вызывает API Github.

Скажем, у меня есть страница в моем приложении, которая показывает имена файлов репо и содержимое README. Это означает, что мне нужно будет сделать несколько вызовов API, чтобы получить это.

Теперь, скажем, я хочу добавить что-то вроде memcached между ними, поэтому я не повторяю эти вызовы снова и снова, если мне это не нужно.

Как вы обычно это делаете? Если я не включу webhook в Github, я не знаю, должен ли истекать кеш. Я всегда мог сделать один звонок, чтобы получить текущий sha HEAD, и если он не изменился, используйте кеш. Но это на уровне репо, а не на уровне файлов.

Я могу себе представить, что я мог бы сделать что-то подобное с помощью объекта-ша, но если мне нужно все-таки вызвать API, он победит цель кэширования.

Как бы вы поступили? Я знаю, что служба, например prose.io, не имеет кеширования прямо сейчас, но если это нужно, каков будет подход?

Ответы

Ответ 1

Будет ли использование кеширования HTTP достаточно хорошим для вашего использования? Цель кеширования HTTP заключается не только в том, чтобы предоставить способ не делать запросы, если у вас уже есть свежий ответ, скорее - он также позволяет быстро проверить, действительно ли ответ, который у вас уже есть в кеше (без отправки сервера ответ снова, если он свежий).

Глядя на ответы API GitHub, я вижу, что GitHub правильно устанавливает соответствующие HTTP-заголовки (ETag, Last-modified, Cache-control).

Итак, вы просто делаете GET, например. для:

GET https://api.github.com/users/izuzak/repos

и это возвращает:

200 OK
...
ETag:"df739f00c5053d12ef3c625ad6b0fd08"
Last-Modified:Thu, 14 Feb 2013 22:31:14 GMT
...

В следующий раз вы выполняете GET для одного и того же ресурса, но также предоставляете соответствующие заголовки кэширования HTTP, чтобы на самом деле это было условное GET:

GET https://api.github.com/users/izuzak/repos
...
If-Modified-Since:Thu, 14 Feb 2013 22:31:14 GMT
If-None-Match:"df739f00c5053d12ef3c625ad6b0fd08"
...

И вот и вот - сервер возвращает 304 Не измененный ответ, и ваш HTTP-клиент вытащит ответ из своего кеша:

304 Not Modified

Итак, API GitHub выполняет кеширование HTTP правильно, и вы должны его использовать. Конечно, вы должны использовать HTTP-клиент, который также поддерживает кеширование HTTP. Лучше всего, если вы получите 304 не измененный ответ - GitHub не уменьшает вашу оставшуюся квоту API-вызовов. См.: http://developer.github.com/v3/#conditional-requests

API GitHub также устанавливает заголовок Cache-Control: private, max-age=60, поэтому у вас есть 60 секунд свежести - это означает, что запросы на один и тот же ресурс, сделанный менее чем на 60 секунд, даже не будут сделаны на сервере.

Ваши рассуждения об использовании единого условного запроса GET для ресурса, который, несомненно, изменится, если что-либо в репо изменилось (например, ресурс, показывающий sha HEAD), разумно - поскольку, если этот ресурс не изменился, тогда вам не нужно проверять отдельные файлы, так как они не изменились.