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