你提出的问题无法简单地用几段话回答或解决。尽管如此，以下是我的尝试...
首先，你所采用的方法存在一些困难：
1.客户端必须始终连接到网络才能创建数据并从服务器接收密钥。
2.如果您确实创建了不同的存储（本地存储和REST），则需要查看两个存储中的所有应用程序代码，这显着增加了应用程序的每个部分的复杂性。
3.创建行后，如果要创建子行，则必须等待服务器返回主键，然后才能将其用作子行中的外键。对于任何中等复杂的数据结构，这都成为了沉重的负担。
4.当服务器关闭时，所有客户端都无法创建数据。
这是我的方法。它使用
SequelSphereDB，但大多数概念可以在其他客户端数据管理系统中重用。
首先：使用UUID作为主键。
大多数客户数据管理系统应该提供一种生成通用唯一标识符的方法。SequelSphere使用SQL函数UUID()来简单地实现这一点。将UUID作为每行的主键允许在任何时间在任何客户端上生成主键，而无需联系服务器，并且仍然保证ID是唯一的。这也使应用程序能够在“离线”模式下工作，在运行时不需要连接服务器。这还可以防止宕机的服务器导致所有客户端都崩溃。
第二：使用与服务器镜像的单个表集。
这更多是为了简单而非其他任何原因。这也是下面两个基本原则的要求。
第三：对于小数据集的向下同步，从服务器完全刷新客户端数据更可取。
尽可能地从服务器上进行完整的数据刷新。这是一个更简单的范例，并且会导致较少的内部数据完整性问题。主要缺点是数据传输大小。
第四：对于大数据集的向下同步，请执行“事务性”更新。
这里的方法会更加复杂。如果数据集过大，需要仅同步更改行，则必须按照“事务”进行同步。也就是说：按在服务器上执行它们的插入/更新/删除操作的顺序提供一个简单的脚本，在客户端执行相同操作。
最好在服务器上有一张记录要同步到设备的事务表。如果不可能，则可以经常在服务器上使用时间戳记录顺序，并让客户端请求自某个时间戳以来所有更改。缺点：您需要通过“逻辑”删除或在其自己的表中跟踪已删除的行来跟踪它们。即使如此，将复杂性隔离到服务器上比将其分散到所有客户端中更可取。
第五：对于向上同步，请使用“事务性”更新。
这就是
SequelSphereDB的亮点：它会为您跟踪所有针对表执行的插入、更新和删除操作，并在同步时将它们提供给您。它甚至可以在浏览器重新启动时完成，因为它将信息持久化在localstorage/indexeddb中。它甚至可以适当地处理提交和回滚。客户端应用程序可以像往常一样与数据交互，而无需考虑记录更改，然后使用SequelSphereDB的“变更跟踪器”在同步时重放更改。
如果您
没有使用 SequelSphere（您应该使用），则在客户端上保留单独的表以记录客户端执行的所有插入、更新和删除操作。每当客户端应用程序插入/更新/删除行时，在“事务”表中复制该行。在向上同步时，发送这些数据。在服务器上，按照相同的顺序执行相同的步骤以复制客户端上的数据。
还有一点很重要：始终在完全从服务器刷新客户端表之前执行向上同步。 :)
结论
我建议尽可能在许多地方采用简单而不是复杂的方法。在此过程中，使用UUID作为主键非常有帮助。使用某种“更改跟踪器”也非常有用。使用诸如SequelSphereDB之类的工具来跟踪更改最有帮助，但对于这种方法并非必需。
完全披露：我与SequelSphere公司有密切关系，但实施上述方法并不需要该产品。
