如何通过Apps Script实现Google Contacts变更的轮询检测

我之前也碰到过类似的需求，确实Google Contacts v3 API和People API都没有原生的变更推送机制，轮询是目前最可行的替代方案。你可能没注意到v3 API里其实有支持轮询的参数，这里给你几个具体的实现思路：

1. 利用updated-min参数实现增量查询 #

这是v3 API里最直接的轮询方式，你可以在每次请求联系人列表时，带上updated-min参数，指定上次轮询结束的UTC时间戳。这样API只会返回在这个时间点之后被创建或修改的联系人。

具体步骤：

• 第一次请求时，记录当前的UTC时间作为基准时间；
• 后续每次轮询，都将上次记录的基准时间作为updated-min的值传入；
• 处理返回的增量联系人数据后，更新基准时间为当前UTC时间（或者返回结果中最新的updated字段值）。

注意：一定要使用UTC时间，避免时区差异导致漏检或重复检测；同时控制轮询频率，建议根据业务需求设置为15分钟到1小时一次，避免触发Google API的限流机制。

2. 结合ETag与If-None-Match实现高效轮询 #

每个联系人资源都有一个etag属性，当联系人的任何信息发生变更时，这个值会随之改变。你可以利用这个特性来减少不必要的数据传输：

• 首次请求时，获取所有联系人的etag并存储起来（比如存在数据库或本地缓存中）；
• 后续轮询时，在请求头中加入If-None-Match字段，值为上次存储的所有etag的集合；
• 如果没有联系人变更，API会返回304 Not Modified，你可以跳过数据处理；如果有变更，API会返回更新后的联系人数据，你再同步更新存储的etag。

这种方式适合联系人数量不多的场景，能有效节省带宽和处理资源。

3. 迁移到People API的增量查询 #

如果你考虑升级到较新的People API，也可以用类似的逻辑实现轮询：

• 使用people.connections.list接口，通过updateTime参数设置过滤条件（比如updateTime >= "2024-01-01T00:00:00Z"），只获取指定时间之后更新的联系人；
• 同样需要记录每次轮询的基准时间，逐步更新。

额外注意事项 #

• 分页处理：如果联系人数量较多，单次请求可能无法返回所有结果，记得处理分页（v3 API用start-index和max-results，People API用pageToken）；
• 错误重试：网络波动或API限流可能导致请求失败，建议实现重试机制，配合指数退避策略；
• 权限范围：确保你的API调用权限包含读取联系人的权限，避免因权限不足导致请求失败。

内容的提问来源于stack exchange，提问作者user14097394