长话短说，我想明确指出用于计算资源的HTTP ETag标头的给定哈希算法(SHA256(。我的理解是，ETag 标头值在设计上是不透明的，但在实践中，使用哈希函数计算它是很常见的。
我理解保持 ETag 值不透明的想法，我想这是为了防止通过缓存代理进行意外优化，这些代理会尝试解释其值并做一些事情，而不是将当前 ETag 与缓存的 ETag 进行比较。但是，我想知道是否有人编写了一个 RFC，定义了附加 HTTP 标头的用法，该标头将明确指示用于计算相应 ETag 值的哈希算法，从而使其不透明，同时与仅依赖于不透明 ETag 值的缓存代理兼容。
就我而言，我没有使用缓存代理：我有一个本机应用程序，它应该从自己的 HTTP 微服务获取多个资源，这意味着我控制 HTTP 客户端和服务器实现。其中一些资源旨在存储在磁盘上，作为优化，我想简单地加载当前文件，计算它的 SHA256 总和，并在再次从我的微服务获取相同资源时将其用作最后一个缓存资源的 ETag。
换句话说：我对不经常更改的特定资源发出 GET 请求，但我仍然需要定期检查。我想计算文件的 SHA256 总和并将其用作 ETag，而不是每次都通过网络传输资源，这样我就可以避免将不透明的 ETag 与文件一起保存。由于我控制为资源提供服务的微服务，因此我可以轻松地将 SHA256 总和用作 ETag，并添加一个自定义标头以指示 SHA256 用于计算 ETAg。此 ETag 对于不检查自定义标头的客户端可以保持不透明，但可以检查的客户端会将其视为 SHA256 总和。
有没有这样的东西的已知实现？我可以使用一个不被广泛认可的晦涩的RFC，或者一些REST API文档，但我宁愿在制作自己的设计之前寻找我可以实现的现有设计。如果我错过了广泛认可的标准，那将比我希望的:)
REST 服务的语义不是由任何标准或 RFC 给出的。只有您可以指定 REST 服务的语义。该规范在HTTP(等(的基本约束之上添加了约束或解释。如果要指定服务返回的ETag是表示形式的 SHA256 校验和，则可以。不需要更多。您不需要特殊的额外标头，也不需要符合某些外部生产的标准。