例如,Squid是受欢迎的HTTP缓存,默认情况下不会缓存具有查询字符串的任何URL.此外,许多客户端甚至服务器和中介都以未定义的顺序生成和使用查询字符串参数;也就是说,“？a = 3& b = 5”可以任意改写为“？b = 5& a = 3”.但是,对于HTTP缓存,顺序很重要,即使内容相同,两个页面也将被单独缓存.当您添加参数时,此问题呈指数增长.

您应该设计您的资源(及其表示)以利用两种相反但互补的技术来缓存：

>将分散和部分表示组合成更大,统一的表示,以及
>沿着缓存边界(这往往是事务性边界)将较大的统一表示分割成较小的表示,但与超链接相关.

在您的情况下,步骤1意味着将关联和部分组合到“用户”表示中,而无需客户端配置哪些和多少的选项.这将允许您积极缓存单个响应表示,而不会由于所有查询字符串选项而使您的(及其)缓存由于响应的组合爆炸而超载.

步骤2意味着将/users.json分为单独的“用户”实体,每个实体都有“关联”资源和“零件”资源.所以/ users / {id}和/ users / {id} /关联和/ users / {id} / parts. “/ users”资源然后返回一个超链接数组到个人“/ users / {id}”资源,每个“/ users / {id}”表示包含到其关联和部分的超链接(这部分更有韧性 – – 可能更适合您的应用程序,将关联和部件直接嵌入到用户资源中),这将允许您积极缓存每个“需求”资源的响应,而无需缓存整个数据库.

那么你的用户会尖叫“但这是网络流量的10倍！”你平静地回应,“不,这是网络流量的1/10,因为10个中的9次请求的资源已经坐在客户端(浏览器)缓存中(当它们不是时,它是1/10服务器的计算资源,因为它们位于服务器端缓存中,当它们不在那里时,我们也避免在服务器上加上智能缓存.“

当然,如果/ users资源是每天有超过一百万新访客,那么您的优化路径可能会有所不同.但是,它似乎没有基于您的示例URI方案.