REST API列表场景下单个资源的ETag实现方案咨询

现有方案的缺陷评估 #

你提出的在UserModel中新增单实体ETag字段的方案，不存在严重缺陷，是工业界普遍采用的成熟实现：

• 你担心的不符合HTTP 1.1标准的问题实际不存在：HTTP标准仅规定GET /users/{Id}接口响应头的ETag需对应当前单用户资源的实体标签，你将该值透传到列表接口的UserModel中属于业务层的字段扩展，完全没有违反HTTP协议规范。
• 仅有的可预期的小成本问题：
  • ETag生成逻辑需要对齐：必须保证列表接口返回的用户ETag值，和GET /users/{Id}接口响应头的ETag值完全一致，避免校验逻辑失效
  • 极小的性能损耗：如果采用强ETag需要每次用户更新时计算实体哈希，若对更新判断精度要求不高，直接使用用户数据的updated_at时间戳转整数作为弱ETag即可，几乎没有额外开销
  • 列表接口传输量小幅上升：每个用户实体多携带十几位的字符串，对接口性能的影响可以忽略不计

更优雅的可选实现方案 #

如果不想修改现有列表接口的返回结构，可以根据业务场景选择以下方案：

• 新增批量ETag查询接口：新增GET /users/etags?ids=1,2,3接口，支持传入最多50~100个用户ID，批量返回对应ID的ETag值，相比逐个调用单用户接口校验，可减少90%以上的请求次数
• 新增增量同步接口：新增GET /users/updates?last_sync_time=xxxx，接口返回上次同步时间之后所有新增、修改、删除的用户数据，用户量越大，该方案的同步效率越高
• 用更新时间替代ETag：在UserModel中新增updated_at字段，用户访问详情时携带If-Modified-Since请求头做校验，逻辑与ETag基本一致，仅时间精度到秒，适合对更新判断精度要求不高的场景

另外你提到的WebDAV标准中的DAV:getetag属性就是同类设计思路，包括主流云服务商的对象存储列表接口，也都会返回每个对象的单独ETag，该方案的通用性无需担心。

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