Support for caching

[di]

Other vulnerability APIs such as PyPI's JSON API provide support for caching, allowing the client to avoid making multiple identical requests via ETag headers.

The OSV API's use of POST requests makes this somewhat challenging, as POST responses are not usually cached.

How should OSV support caching, and how should OSV clients cache responses?

[oliverchang]

We had another similar FR from another party.

My understanding of the relevant HTTP headers is weak, but my understanding is we could leverage two potential headers:

• If-None-Match with Etags.
• If-Modified-Since and re-using our modified timestamps in the returned OSV responses.

As @di mentioned though, POST may make this a slight misuse of these headers.

As for implementing them, I'm not sure if this is something ESPv2 woulds support today, so it may be a little challenging.

[oliverchang]

One other consideration here is that caching is not going to be saving much time with the actual query itself -- OSV.dev will still need to compute the actual query before any ETags or similar are returned. This would only save traffic and the costs associated with that.

[di]

One other consideration here is that caching is not going to be saving much time with the actual query itself -- OSV.dev will still need to compute the actual query before any ETags or similar are returned. This would only save traffic and the costs associated with that.

I'm not sure this is true. If OSV were cached behind a CDN, the CDN could return the same response with the same ETags until OSV determined that the underlying data was changed and issued a purge to invalidate the cache -- only then would another query need to be computed on the next request for a given response.

As @di mentioned though, POST may make this a slight misuse of these headers.

Yeah, I don't think this is a good path to go down. Maybe a better question: why is this a POST request? Could we transition to an API that supports GET requests instead?

[andrewpollock]

Caching was touched on in #2239 as well.

[github-actions]

This issue has not had any activity for 60 days and will be automatically closed in two weeks

See https://github.com/google/osv.dev/blob/master/CONTRIBUTING.md for how to contribute a PR if you're interested in helping out.

[oliverchang]

Leaving this as a backlog item as we don't see this as enough of a priority to justify the large engineering investment here. Please comment here if anybody disagrees!