5

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

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

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

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

我是否：

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

优点：

  • 这允许客户端不必N为了显示资源列表而执行多次请求
  • items当客户端更新项目时，允许任何缓存失效。

缺点：

  • 这对我来说并不“干净”，因为我并没有真正更新集合，而是一个单独的项目。
  • 这会使整个集合的缓存无效，而不是更改的单个项目的缓存。

或者

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

优点：

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

缺点：

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

2 回答 2

2

我曾经有过类似的需求，一位客户想知道最新的更新项目。为此，我使用“最后更新”参数增强了我的收藏资源：


GET /items?modifiedAfter=2011-10-10/10:10:10

然后需要将此 modifiedAfter 信息附加到后端某处的项目数据。Api-Clients 可以自己决定他们想要抓取多少或多远的过去。完整查询和增量查询都易于实现。

尝试在集合上使用 PATCH 和缓存非常困难，而且绝非易事（使用标准的 E-Tag 标头，显示“正确”的感兴趣的项目等，硬客户端实现）。主要问题是，集合通常具有非常动态和不断变化的行为。

最后，modifiedAfter服务器端和 api 客户端都对收集资源感到满意。

除了缓存问题之外，还要评估您是否真的需要部分更新。在大多数情况下，我更喜欢更简单的完整更新（使用PUT）。

于 2011-10-27T18:59:07.933 回答
2

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

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

于 2011-10-27T12:04:19.130 回答