这个问题有点笼统，所以为了帮助缩小焦点，我将分享我当前的设置，它激发了这个问题。我有一个运行 RESTful API 的 LAMP Web 服务。我们有两个客户端实现:一个基于浏览器的 javascript 客户端(本地存储)和一个基于 iOS 的客户端(核心数据存储)。显然这两个客户端存储数据的方式非常不同，但数据本身需要尽可能多地与远程服务器保持双向同步。
目前，我们的“同步”过程有点愚蠢(如非智能)。从概念上讲，它看起来像:
数据本身以关系方式存储，并由客户端用户偶尔更新。在我的特定情况下，客户端不太关心关系本身(这就是为什么我们现在可以在浏览器客户端中使用本地存储)。
显然这不是真正的同步。我想转移到一个系统，从概念上讲，最近更改的“差异”会定期发送到服务器，服务器会发回它所知道的最新更改的“差异”。达到这一点似乎很难，但也许我只是不太了解这个问题。
REST感觉是一个好的开始，但 REST 只讨论两个数据存储相互通信的方式，而不是数据本身如何在它们之间同步。 (这个同步过程由每个商店的实现者决定。)实现这个过程的最佳方法是什么？是否有一套现代的编程设计模式适用于为这个问题提供特定的解决方案？如果可能的话，我最感兴趣的是通用的(技术不可知的)方法……但是如果存在特定的框架，那么查看它们也会很有用。
最佳答案
多主复制总是(并且将永远是)困难和定制，因为如何处理冲突将特定于您的应用程序。
IMO 更强大的方法是使用主从复制，将您的 Web 服务作为主服务器，将客户端作为从服务器。要保持客户端同步，请使用更改的存档原子提要(参见 event sourcing) 和 RFC5005 。这是您将获得的最接近此类复制的现代标准的方法，它是 RESTful。
当客户端在线时，它们不会直接更新其副本，而是向服务器发送命令并通过原子提要更新其副本。
当客户离线时，事情就变得困难了。您的客户需要有一个关于您的 Web 服务行为的模型。它需要有副本的离线副本，应该是 copied on write来自在线副本(在线副本是由原子提要更新的副本)。当客户端执行修改数据的命令时，它应该存储命令(用于稍后针对 Web 服务重放)、预期结果(用于重放期间的验证)并更新离线副本。
当客户端重新上线时，它应该重放命令，将结果与预期结果进行比较，并将任何差异通知客户端。如何处理这些差异将根据您的应用程序而有所不同。然后可以丢弃离线副本。
关于web-services - 用于在 Web 服务和客户端之间同步数据的现代编程标准是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15775171/