假设以下场景Web 应用程序通过 RESTful API 提供资源。许多客户端使用此 API。目标是保持客户端上的数据与 Web 应用程序同步（双向）。
最简单的方法是询问 API 自客户端上次与 API 同步以来是否有任何资源发生更改。这意味着客户端需要向 API 请求带有时间戳的适当资源（以查看数据是否需要更新）。在我看来，就不必要的带宽消耗而言，这似乎是开销最小的方法。
但是，我觉得这种方法在设计和责任方面有一些缺点。例如，API 不应该处理检查资源是否过期的问题。似乎 API 的唯一职责应该是在被询问时提供资源，而不必处理更新方面。通过采用第二种方法，客户端每次想要更新其数据以使其与 Web 应用程序保持同步时都会请求大量数据。换句话说，客户端会检查它返回的数据是否比本地存储的数据更新。如果此过程每隔几分钟发生一次，这可能会成为系统的重大负担。
我是否正确地看到了这一点，还是我忽略了一条中间道路？
这是一个很常见的问题，RESTful 方法可以帮助您解决它。HTTP（通常用于构建 RESTful 服务的应用程序协议）支持多种技术，可用于使 API 客户端与服务器端的数据保持同步。
如果客户端在 HTTP 响应中接收到Last-Modifiedor标头，它可能会使用该信息在将来进行有条件的 GET调用。这允许服务器通过响应快速指示客户端先前存储的资源表示仍然有效且准确。这将允许服务器（或者甚至更好的中间代理或缓存服务器）尽可能高效地响应客户端的请求，从而潜在地减少到后端数据存储的昂贵往返。E-Tag304 – Not Modified
如果响应包含Last-Modified标头并且客户端希望利用可用的性能优化，则它们必须If-Modified-Since在对同一 URI 的后续 GET 调用中包含一个指令，并传入它接收到的相同时间戳值。这指示服务器仅在知道自那时起已更改时才从权威后端源获取信息。当然，您的服务器必须构建为支持这种技术。
类似的原则适用于E-Tag标题。AnE-Tag是一个简单的哈希码，表示资源在特定时间点的特定状态。如果资源发生任何变化，它的E-Tag价值也会发生变化。如果客户端在响应中看到一个E-Tag，它应该在随后的 GET 请求中将它传递给相同的 URI，从而允许服务器快速确定客户端是否具有资源的最新表示。
最后，您可能应该查看长轮询技术，以减少客户端向服务器发出的重复 GET 请求的数量。本质上，诀窍是向服务器发出很长的 GET 请求以监视服务器数据的变化。GET 将不会返回响应，直到数据发生更改或很长的超时触发。如果是后者，客户端只需重新发出相同的长期请求以再次监视更改。另请参阅方法类似的Comet 和 Web Sockets等主题。