Architecture 如何为设备和服务器之间的元数据同步设计高级应用程序协议和数据格式？

我正在寻找关于如何最好地考虑设计一个高级应用程序协议以在最终用户设备和服务器之间同步元数据的指导

我的目标是：用户可以在任何设备或web上与应用程序数据交互。此协议的目的是通过服务器将在一个端点上所做的更改传递给其他端点，并确保所有设备保持应用程序数据的一致性。如果用户在一台设备或web上进行更改，该协议将把数据推送到中央存储库，其他设备可以从中提取数据

其他一些设计思想：

• 我称之为“元数据同步”，因为有效负载将非常小，以对象ID和关于这些ID的小元数据的形式出现。当客户端端点通过此协议检索新元数据时，它们将基于此元数据从外部源获取实际对象数据。获取“真实”对象数据超出范围，我这里只讨论元数据同步
• 使用HTTP进行传输，使用JSON进行有效负载容器。问题基本上是关于如何最好地设计JSON有效负载模式
• 我希望这是易于实施和维护的网络和跨桌面和移动设备。最好的方法是简单的基于计时器或事件的HTTP请求/响应，没有任何持久通道。另外，你不应该有博士学位来读它，我希望我的说明书能放在2页，而不是200页
• 身份验证和安全性超出了这个问题的范围：假设请求是安全的和经过身份验证的
• 目标是设备上数据的最终一致性，而不是完全实时的。例如，用户可以在脱机时在一台设备上进行更改。当再次联机时，用户将执行“同步”操作以推送本地更改并检索远程更改
• 话虽如此，协议应支持这两种操作模式：
  • 从设备上从头开始，应该能够提取整个元数据图片
  • “边走边同步”。当并排查看两台设备上的数据并进行更改时，应该可以轻松地将这些更改作为单独的短消息推送到另一台设备上，另一台设备可以近实时地接收到这些消息（取决于它决定何时联系服务器进行同步）

作为一个具体的例子，你可以想到Dropbox（这不是我正在研究的，但它有助于理解模型）：在一系列设备上，用户可以管理文件和文件夹，移动它们，创建新的，删除旧的等等。在我的上下文中，“元数据”将是文件和文件夹结构，但不是实际的文件内容。元数据字段类似于文件/文件夹名称和修改时间（所有设备都应该看到相同的修改时间）

另一个例子是IMAP。我没有读过协议，但我的目标（减去实际的消息正文）是一样的

感觉有两种方法可以实现这一点：

• 事务性消息。系统中的每个更改都表示为增量，端点与这些增量通信。示例：DVCS变更集
• REST：将对象图作为一个整体或部分进行通信，而不用太担心单个原子的变化

编辑：一些答案正确地说，没有足够的应用信息提供足够好的建议。该应用程序的确切性质可能会让人分心，但一个非常基本的RSS阅读应用程序是一个足够好的近似。假设应用程序规范如下所示：

• 有两个类：feed和items
• 我可以添加、重命名和删除提要。添加一个提要将订阅该提要并开始接收该提要的项。我还可以在UI中重新排序提要显示顺序
• 当我读取项目时，它们被标记为已读。我不能将它们标记为未读或对它们做任何其他事情
• 基于上述内容，对象模型为：
  • “提要”具有“url”、“displayName”和“displayOrder”属性（displayOrder是UI提要列表中提要的索引；对提要进行本地重新排序会更改所有提要的displayOrder，以便索引保持唯一和顺序）
  • “item”具有属性“url”和“unread”，以及多对一关系“feed”（每个项属于一个feed）。“url”还充当项目的GUID
  • 实际项目内容在每个设备上本地下载，不属于同步的一部分

基于这种设计，我可以在一台设备上设置我的应用程序：添加一堆提要，对它们进行重命名和重新排序，并读取其中的一些项目，然后将它们标记为未读。当我切换设备时，另一个设备可以同步配置，并向我显示相同的提要列表，具有相同的名称、顺序和相同的项目读取/未读取状态

（结束编辑）

我想在答案中说明：

• 上面我遗漏了什么重要的东西吗？限制、目标
• 这方面有什么好的背景资料？（我意识到这正是许多计算机科学课程详细讨论的内容……我希望通过看一些速成班或金块来缩短它。）
• 我可以仿效，甚至开箱即用的此类协议的好例子有哪些？（我在上面提到Dropbox和IMAP…我可能应该阅读IMAP RFC。）
有几点想法：
1） 。您可以对变更通知交付的可靠性做出哪些假设？这些通知排序的可靠性如何？我的建议是，最好通过恢复请求完全重新交付元数据来容忍丢失和错误订购
2） 。实际上，您有一个元数据流，也有一个数据流。您可以对它们的相对顺序做出哪些假设。您能否在m之前接收新版本的数据