缓存 Github API 调用 [英] Caching Github API calls

问题描述

我有一个与 API 调用缓存相关的一般性问题，在本例中是对 Github API 的调用.

I have a general question related to caching of API calls, in this instance calls to the Github API.

假设我的应用程序中有一个页面，其中显示了存储库的文件名以及自述文件的内容.这意味着我将不得不调用一些 API 来检索它.

Let's say I have a page in my app that shows the filenames of a repo, and the content of the README. This means that I will have to do a few API calls in order to retrieve that.

现在，假设我想在两者之间添加诸如 memcached 之类的东西，所以如果我不需要，我不会一遍又一遍地执行这些调用.

Now, let's say I want to add something like memcached in between, so I'm not doing these calls over and over, if I don't need to.

你通常会怎么做?如果我不在 Github 上启用 webhook，我就无法知道缓存是否应该过期.我总是可以通过一次调用来获取 HEAD 的当前 sha，如果它没有改变，请改用缓存.但这是在存储库级别，而不是在文件级别.

How would you normally go about this? If I don't enable a webhook on Github, I have no way of knowing whether the cache should expire. I could always make a single call to get the current sha of HEAD, and if it hadn't changed, use cache instead. But that's on a repo-level, and not on a file level.

我可以想象我可以用 object-sha 做类似的事情，但是如果我无论如何都需要调用 API 来获取这些，它就违背了缓存的目的.

I can imagine I could do something like that with the object-sha's, but if I need to call the API anyway to get those, it defeats the purpose of caching.

你会怎么做?我知道像 prose.io 这样的服务目前没有缓存，但如果应该，会采用什么方法?

How would you go about it? I know a service like prose.io has no caching right now, but if it should, what would the approach be?

谢谢

推荐答案

仅使用 HTTP 缓存是否足以满足您的用例?HTTP 缓存的目的不仅仅是提供一种在您已有新响应的情况下不发出请求的方法，而是 - 它还使您能够快速验证缓存中已有的响应是否有效(无需服务器发送完整的响应)新鲜的话再回复).

Would just using HTTP caching be good enough for your use case? The purpose of HTTP caching is not just to provide a way of not making requests if you already have a fresh response, rather - it also enables you to quickly validate if the response you already have in cache is valid (without the server sending the complete response again if it is fresh).

查看 GitHub API 响应，我可以看到 GitHub 正确设置了相关的 HTTP 标头(ETag、Last-modified、Cache-control).

Looking at GitHub API responses, I can see that GitHub is correctly setting the relevant HTTP headers (ETag, Last-modified, Cache-control).

因此，您只需执行 GET，例如对于:

So, you just do a GET, e.g. for:

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:

Next time - you do a GET for the same resource, but also supply the relevant HTTP caching headers so that it is actually a conditional 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 Not modified 响应，你的 HTTP 客户端将从它的缓存中提取响应:

And lo and behold - the server returns a 304 Not modified response and your HTTP client will pull the response from its cache:

304 Not Modified

因此，GitHub API 正确执行 HTTP 缓存，您应该使用它.当然，您还必须使用支持 HTTP 缓存的 HTTP 客户端.最好的事情是，如果您收到 304 Not modified 响应 - GitHub 不会减少您剩余的 API 调用配额.请参阅:https://docs.github.com/en/rest/overview/resources-in-the-rest-api#conditional-requests

So, GitHub API does HTTP caching right and you should use it. Granted, you have to use an HTTP client that supports HTTP caching also. The best thing is that if you get a 304 Not modified response - GitHub does not decrease your remaining API calls quota. See: https://docs.github.com/en/rest/overview/resources-in-the-rest-api#conditional-requests

GitHub API 还设置了 Cache-Control: private, max-age=60 标头，因此您有 60 秒的新鲜度——这意味着对相同资源的请求不到 60 秒甚至不会对服务器进行分离.

GitHub API also sets the Cache-Control: private, max-age=60 header, so you have 60 seconds of freshness -- which means that requests for the same resource made less than 60 seconds apart will not even be made to the server.

您关于对资源使用单个条件 GET 请求的推理，如果 repo 中的任何内容发生更改(例如，显示 HEAD 的 sha 的资源)肯定会更改，这听起来很合理——因为如果该资源没有更改，那么您不必检查单个文件，因为它们肯定没有更改.

Your reasoning about using a single conditional GET request to a resource that surely changes if anything in the repo changed (a resource showing the sha of HEAD, for example) sounds reasonable -- since if that resource hasn't changed, then you don't have to check the individual files since they haven't surely changed.

这篇关于缓存 Github API 调用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！