假设以下场景 Web应用程序通过RESTful API提供资源。许多客户端使用此API。目标是使客户端上的数据与Web应用程序保持同步（在两个方向上）。
最简单的方法是询问API自客户端上次与API同步以来是否有任何资源发生了变化。这意味着客户端需要向API询问是否附带时间戳的相应资源（以查看是否需要更新数据）。在我看来，这就像在不必要的带宽消耗方面开销最小的方法一样。
但是，我觉得这种方法在设计和责任方面有一些缺点。例如，API不应该处理检查资源是否过期的问题。似乎API的唯一责任应该是在被要求时提供资源而不必处理更新方面。通过遵循第二种方法，客户端每次想要更新其数据时都会要求大量数据，以使其与Web应用程序保持同步。换句话说，客户端将检查它返回的数据是否比本地存储的数据更新。如果此过程每隔几分钟发生一次，这可能会成为系统的重大负担。
我是否正确地看到了这一点，或者我正在俯瞰中间道路？
答案 0 :(得分：18)
这是一个非常常见的问题，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，从而允许服务器快速确定客户端是否具有该资源的最新表示。
最后，您应该查看long polling technique以减少客户端向服务器发出的重复GET请求的数量。本质上，诀窍是向服务器发出非常长的GET请求以监视服务器数据的变化。在数据发生更改或超时超时之前，GET不会返回响应。如果是后者，客户端只需重新发出相同的长期请求以再次监视更改。另请参阅类似于Comet and Web Sockets的主题。