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