我正在创建一个 RESTful API（使用 MVC.NET）来允许外部访问业务系统。API 包含一个搜索资源。该资源采用 URI 形式“/example/search/pages/1/?query=something”。
示例：要搜索披萨，您将访问 URI“/example/search/pages/1/?query=pizza”，这将为您提供前 10 个结果。要获得结果的第二页，您需要请求“/example/search/pages/2/?query=something”等。
我使用了缓存控制 HTTP 标头来启用 API 上所有资源的公共缓存，目的是显着减少服务于 API Web 应用程序的服务器上的负载。
但是我不确定要为搜索资源使用什么缓存策略。由于资源（以及它的 URI）根据您搜索的内容而有所不同，因此缓存页面似乎没有什么意义。人们为 RESTful API 上的搜索资源推荐什么缓存策略（即通过缓存控制 HTTP 标头进行缓存）？没有缓存？到期时间很短的私人缓存？有效期短的公共缓存？
大多数代理不会缓存任何使用查询字符串的内容。
如果您想要缓存，我建议您使用 POST-Redirect-GET 模式为您的搜索请求制作新的 URI。
POST 搜索内容类型：application/x-www-form-urlencoded
术语=某事
303 查看其他位置：/search/something/1
这将更积极地启用缓存，但您必须制作这些 URI，并且仍然会受到初始 POST 的影响。也就是说，如果是查询有问题，这将很好地解决问题。
具有适当 max-age 的公共缓存是您想要的 - max-age 的值将是特定于应用程序的，并且是您必须做出的主观判断调用。
您必须平衡提供陈旧响应的风险与不必计算每个请求的回报。如果这种风险非常高，则缩短时间 - 但请注意，这样做会增加原始服务器的负载。监视使用模式和服务器负载是一个好主意，以便确定您的初步判断是正确的。
这不是您的问题的一部分，但如果我是您，我会将分页移动到 URI 的查询部分，所以
/example/search/pages/1/?query=something
会成为：
/example/search?term=something&page=1
这不是必需的，但对开发人员来说会更直观，您可以使用 HTML 表单更轻松地实现它