YouTube 数据 API v3：ChannelListResponse、PlaylistListResponse 和 PlaylistItemListResponse 的 etag 实现中断

Question

我已于 2019 年 7 月 23 日在 Google's bug tracker 上提出了以下问题，如果 YouTube 的数据 API v3 中修复此问题，我从未得到答复。

问题在于，YouTube 数据 API v3 的当前 etag 实现不适用于 ChannelListResponse、PlaylistListResponse 和 PlaylistItemListResponse，因为 etag 在每次请求时都会更改，即使相应请求背后的数据没有更改。这使得无法缓存这些数据并减少 API 请求的数量。链接的 stackoverflow 答案解释了这种行为的原因可能是 API 在每个请求中以另一个顺序返回项目，因此设置了一个新的 etag。

如何重现：

1. 点击this link查看etag
2. 再次单击链接（多次），您会看到 etag 不时更改

这个 etag 行为在 PlaylistItemListResponse.Item 实体（实际上是一个视频）上正常工作，只要视频的数据没有改变，etag 就始终保持不变。因此，在 YouTube 数据 API v3 上处理 etag 的方式明显不同。

知道是否有解决方法或者此问题是否会在某一天得到解决？

Answer 1

我将尝试回答以下问题：

对于Channels.list、Playlists.list 和PlaylistItems.list API 端点的etag 属性的众所周知的问题是否有解决方法？

1. Channels.list 端点

在Channels.list 的情况下，事情很简单（但不是微不足道的），因为此端点最多返回 50 个Channel resources。 （通常只有一个，但是当一个人将id参数的值设置为一个逗号分隔的列表——最多50个——频道ID时，他/她将从端点获得几个这样的资源。）

简单性来自这样一个事实，即任何此类通道资源都可以在本地缓存（以从端点接收的原始 JSON 文本形式，或者以其他任何形式保留该资源的所有属性）。然后，在为当前服务器存储的资源调用端点时，可以应用结构性（简单但并非微不足道的）差异操作来查看该资源是否已更改并确定发生的确切更改。

2。 Playlists.list 端点

在Playlists.list 的情况下，事情与第 1 点 w.r.t 的情况完全相似。 Channels.list 端点。

3. PlaylistItems.list 端点

当需要跟踪 w.r.t. 发生的更改时，事情会变得更加复杂。任何给定播放列表的项目。在这种情况下使用PlaylistItems.list 端点，但不幸的是，在这种情况下会出现几个问题：

• 实际上，播放列表可能会变得很大（如果仅考虑某些频道的上传播放列表，其中包含数十万个条目）。

• 根据设计，当查询给定频道的上传播放列表时，an upper 20000 limit 设置为通过 PlaylistItems.list 返回的项目数。

• 由于上面的前两个项目符号，在某些情况下，计算本地缓存和远程存储的播放列表项目列表之间的集合理论差异是不可行的，甚至是不可能的。因此，在一般情况下（即，当人们不考虑某些播放列表的特殊性时），人们无法准确地说出哪些项目被删除、添加到并保留在播放列表中。

YouTube 数据 API 无法让用户确定哪些视频项目已从给定播放列表中删除以及何时删除。然而，该用户很可能会通过使用Activities.list 端点来确定将哪些项目添加到播放列表以及何时发生。

因此，跟踪播放列表发生变化的用户只能部分回答集合理论差异问题，这可以理想地解决他/她的问题。

使用Activities.list 端点的注意事项如下：端点返回一整套发生w.r.t 的活动类型。给定频道（由Activities resource 指定）。 type 属性将它们全部枚举：

snippet.type（字符串）
资源描述的活动类型。

此属性的有效值为：channelItem、comment（当前未返回）、收藏夹、赞 、playlistItem、promotedItem、推荐、社交、订阅、上传、公告（已弃用）。

因此，在监视 Activities.list 时，当 API 用户只对 playlistItem 活动感兴趣时，从端点获得的结果集很可能包含大量噪音。