我是否可以为特定于用户的REST使用电子标签，以避免每次发送相同的数据？

Question

假设我们有一个API来检索特定于用户的数据。由于某些原因，我不希望服务器每次数据不变时都将数据发送回客户端。

例如，我有一个移动应用程序。每次启动时，它都会显示本地缓存中的数据，但也会从后台服务器检索一些特定于用户的数据。我想要做的是，如果数据不变，希望服务器只返回304。

电子标签似乎可以做这种事情，但我不确定它是否是一个好的选择，因为它是一个特定于用户的API。

Answer 1

HTTP是一种请求/响应协议。对于客户端发送的每个请求，服务器将响应。响应可以是失败的，也可以是成功的。除非有一个互联网下降，不应该有一个情况下，一个服务器没有响应！

特别是，ETag通常是资源当前状态的哈希值或预定义的字符串值，即版本计数器的字符串值(正如Evert正确提到的那样)，该值在响应中作为HTTP报头返回，因此客户端可以在希望更改特定状态的情况下使用它，并且不希望服务器在同时修改该资源时更新它(=乐观锁定)。

使用ETags的第二种情况是检查客户端的状态是否仍然是服务器已知的状态，根据资源是否仍然具有相同的ETag值，服务器使用响应进行响应。在这里，您应该向服务器发出一个HEAD请求，以尽量减少来回发送的有效负载，因为您可能感兴趣的是客户端已知的当前版本是否仍然是服务器保存的版本。

..。但我不确定这是否是一个好的选择，因为它是一个特定于用户的API。 ..。我读过一些关于电子标签的文章，但它们都没有提到任何关于用户特定数据的内容。..。

正如吉姆·韦伯所指出的，HTTP的核心是一个传输协议，其域是通过网络传输文档。您最好把它看作是一个文档管理系统，您可以将新文件放到某个位置，删除或检索它们，或者通过POST请求根据服务器本身的语义处理它们。根本上来说，HTTP并不是什么。因此，任何遵循HTTP规则的HTTP客户端都能够利用RFC 7232中指定的条件请求，HTTP服务器也应该如此。因此，数据来源于某些HTTP服务器，还是由一些Java、.Net或任何中间件或框架支持的API，只要它们遵循相同的HTTP协议，就没有区别。如果您愿意的话，某个特定的框架或实现是否支持这种“特性”，不幸的是，这是另一回事。

关于使用条件请求是否是一个好的选择，您有哪些选择？如果客户端想知道它是否拥有资源的最新状态，那么它需要礼貌地询问服务器，客户机知道的版本是否仍然是最近的版本，或者只是检索整个状态(再次)。有些人可能会争辩说，在由于其他客户端的中间更新而导致版本不同的情况下，需要交换多条消息。这是一个有效的论点，但您需要估计哪些可能会更频繁地发生。在这样一种情况下，客户端很少检查其版本是否仍然是当前版本，或者不同客户端经常对该资源进行更新，可能再次检索该资源的整个状态的总字节数可能较少，因此最终效率更高。虽然HTTP提供了请求，但是您可以利用它来最小化客户机和服务器之间交换的有效负载大小，因为HTTP将HEAD定义为

..。服务器不能在响应中发送消息体(即响应终止在标头部分的末尾)。服务器响应HEAD请求应该发送与如果请求是GET时所发送的标题字段相同的头字段，但可以省略有效负载标头字段(3.3节)。该方法可用于在不传递表示数据的情况下获取所选表示的元数据。 HEAD请求消息中的有效负载没有定义的语义；在HEAD请求上发送有效负载体可能会导致某些现有实现拒绝该请求。(来源)

本质上，HEAD请求和对此类请求的响应只包含headers，而没有进一步的消息体，这有助于显著降低交换消息的字节大小。在最好的情况下，在两个版本相等的情况下，您可以最大限度地减少交换的字节。在最坏的情况下，如果他们不同，额外的开销可能是可以忽略的，除非你真的在一个高性能的边缘笼。因此，在您感兴趣的情况下，您目前对某些资源的了解是否仍然是最新的，通过HEAD提出有条件的请求是一个不错的选择。