我一直在尝试了解HTTP Etags并提出了一个示例用法。我的想法是否正确？
假设我们有一些带有自定义链接类型的RESTful API。某些资源返回带有以下链接的XML数据：
＆lt; link rel =＆＃34; http：//my.api/relation_definition" URL =＆＃34; HTTP：//my.api/resources/someId" /＆GT;
请注意自定义rel定义，该定义会导致对该链接含义的某些描述。
现在，如果这个rel描述会提供一个弱Etag。为我的REST api创建客户端的程序员可以将这个etag嵌入到他/她的客户端中。由于自定义关系可能意味着客户端app的某些特殊行为。现在客户端应用程序可以检查链接定义是否有;通过查询弱etag更改了nt。如果它相同，那就没关系。如果弱etag发生变化，则意味着客户可能不得不改变/重新考虑这些链接上的行为，并可能通知其开发人员采取某些行动。
我使用弱etags而不是强etags因为我作为api的提供者可以更频繁地更改链接的描述，修复拼写错误，添加一些示例等，这确实改变了意义。因此，只有在这些链接的含义发生变化时，我才会改变描述的弱标签。
我是否理解弱etags的目的？
答案 0 :(得分：2)
最重要的是要意识到改变ETag，无论是弱还是强，都会导致浏览器重新请求资产。唯一的区别是，当你不改变时，浏览器会信任ETag。
对于＆＃34;对该链接含义的一些描述＆＃34;，听起来好像你在谈论一个带有静态（或接近静态）内容的小文档，所以它没有＆＃39真的很重要，你的ETag是标记为弱还是强，因为浏览器可能不会做任何特殊的事情，可以从强大的ETag的保证中受益。 API客户端可能根本不关心弱ETag和强ETag。
强大的ETag发挥作用的是大量下载（软件，视频，音频等），浏览器可能会使用范围请求来下载资产的一部分。强大的ETag意味着该项是逐字节相同的，因此可以使用先前下载的文件块。例如，想象一下，恢复上周开始的大型下载。如果ETag相同但很弱，浏览器可能会决定重新下载整个文件，而强大的ETag可能会导致恢复现有的下载。
同样，对于您的情况，不要担心。如果您正在使用该文件的哈希值，则可以保证＆＃34;逐字节相同＆＃34;语义，所以继续并称之为强大，但无论哪种方式都应该为你工作相同。同样，API客户可能根本不关心弱ETag和强ETag。
至于何时应更改ETag，除非您每天进行100次更改，否则请在每次更改时进行更改。