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

Question

我该如何在API网关中禁用非200 OK响应的缓存.

对于我们的一个API端点,我们实现了补充节流机制,我们发送了429 HTTP响应.

目的是让客户端在服务器准备好实现它的短时间后重试请求,但现在发生的是API网关缓存初始响应并继续从缓存中发送响应.

Answer 1

根据对AWS API Gateway 缓存能否根据响应内容使特定条目无效的响应？，API 网关缓存似乎没有“有时”缓存结果的功能。该文档显示了一种让客户端发出忽略现有缓存的请求的方法（通过设置Cache-Control: max-age=0），但没有显示服务器说“这是一个不应缓存的一次性响应”的方法.

我认为值得尝试的第一件事是Cache-Control: max-age=0在错误响应中指定一个标头，只是为了尝试看看它是否有效。AWS API Gateway 在底层使用 CloudFront 进行分发，因此它可能会正常工作。

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

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