防止在 AWS API Gateway 中缓存非 200 响应

Question

我应该如何在 API Gateway 中禁用非 200 OK 响应的缓存。

对于我们的一个 API 端点，我们实施了互补的节流机制，并发送了 429 HTTP 响应。

目的是让客户端在服务器准备好完成请求后在短时间内重试请求，但现在发生的情况是 API 网关缓存了初始响应并继续从缓存中发送。

Answer 1

根据对Can AWS API Gateway cache invalidate specific entries based on the response content? 的回复，API 网关缓存似乎没有“有时”缓存结果的功能。 documentation 显示了一种让 client 发出忽略现有缓存的请求的方法（通过设置 Cache-Control: max-age=0），但没有显示 server 的方法em> 表示“这是一个不应缓存的一次性响应。

我认为值得尝试的第一件事是在错误响应中指定像Cache-Control: max-age=0 这样的标头，只是为了尝试它是否有效。 AWS API 网关在后台使用 CloudFront 进行分发，因此它可以正常工作。

如果这不起作用，其他选项包括：

1. 关闭 AWS API Gateway 缓存。如果您需要缓存，请使用 CloudFront 或其他服务设置您自己的缓存，以便更精细地控制缓存哪些响应。
2. 尝试在流程的早期移动节流（我不确定你是否使用内置的API Throttling features），但既然你说你“实施”了你的机制，我猜你是在处理请求的后端自己做。如果您可以在缓存层之前进行限制（无论是内置 API 网关缓存还是其他系统），最终可能会解决您的问题并减轻后端请求处理程序的压力。
3. 在向客户端发送 429 响应后，当服务有空处理更多请求时，使用Cache-Control: max-age=0 发送您自己的“缓存失效”请求以获取缓存的“真实”值。显然，这会有点棘手，因为您需要知道服务何时启动并可以处理更多请求，而不会因为再次“免费”而添加更多请求而再次陷入困境。
4. 根据您的确切缓存需求，在您的缓存设置中设置一个足够低的 TTL。例如，如果一旦启动限制，它可能至少在 60 秒内不再可用，那么拥有 60 秒的 TTL 意味着 429 响应将在这段时间内从缓存中获得。但是，由于您只是在节流，因此您的服务“超载”，您的情况可能可以接受继续提供 429 直到 TTL 到期。不过，对于“成功”和“失败”响应，这需要相同的短 TTL。