REST收集和单个项目的缓存注意事项

Question

我正在开发一个新的REST-ful API，该API的主要/唯一使用者是智能/非Web浏览器客户端。我有一个由后台进程（而不是由客户端本身）维护/更新的集合资源。第一次迭代所需的唯一内容类型是JSON。URI类似于：

• /items/ -代表项目集合的资源。
• /items/123-代表ID为的单个项目的资源123。

虽然客户端将不会创建新项目，也不会更新集合以添加/删除项目，但它将更新单个项目中的某些值。我的计划是使用我自己的JSON补丁格式，使用HTTP PATCH更新项目资源。

将有许多并发客户端读取项目，并同时更新不同的项目，并偶尔对同一项目进行并发更新，尽管允许一定程度的“最终一致性”，但我想将其设计为“缓存友好” “一种可能的方式。阅读RFC的PATCH，我发现对PATCH的成功响应后，如果有响应，则应使用响应更新Request-URI的缓存。问题归结为：

我要：

A）在/items/集合资源JSON 表示中包含各个项目的完整表示，然后将PATCH发送到/items/URI，并以补丁格式包括要更新的项目？

优点：

• 这使客户端不必N为了显示资源列表而执行请求数
• 允许items客户端更新项目时使的所有缓存无效。

缺点：

• 对我来说，这不是“干净”的东西，因为我并不是真正在更新收藏，而是单独更新商品。
• 这会使整个集合的缓存无效，而不是使已更改的单个项目的缓存无效。

要么

B）在资源集合的JSON表示中，仅包括指向所包含项目的链接，并让客户端在发现集合中的哪些项目后请求各个项目。HTTP PATCH将发送到单个项目URI（例如/items/123）

优点：

• 独立地缓存集合和项目资源。单个项目的PATCH可以适当地使该项目的缓存无效。
• API更加清晰，因为您在要更新的特定项目上发出了HTTP PATCH。

缺点：

• 不允许批量更新商品。目前这根本不是必需的，我将来也不会预见，但是事后看来只有20到20岁。
• 要求客户端发出N+1请求以显示项目的完整列表。

Answer 1

我会选择 B。但是你们的客户通常会要求所有的收藏吗（我的意思是他们需要收藏）吗？如果不A选择，将会产生过多的流量。所有项目（因为它们在集合中）都会发生缓存失效。

如果您的客户主要获取整个集合，那么A使用特定项目的查询参数也是一种选择。