rest - REST 集合和单个项目的缓存注意事项

Question

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

/items/ - 代表项目集合的资源。

/items/123 - 代表 ID 为 123 的单个项目的资源.

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

会有许多并发客户端读取项目，并发更新不同项目，偶尔会并发更新同一项目，虽然允许一定程度的“最终一致性”，但我想将其设计为“缓存友好” ” 一种尽可能的方式。阅读 PATCH 的 RFC，我看到在成功响应 PATCH 时，请求 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带有特定项目的查询参数也是一个选项。