javascript - REST API，跟踪多资源变化，前端同步

Question

我有一个业务逻辑相当复杂的系统，到目前为止我有大约 10-15 个数据库表(资源)，而且这个数字还在增长。用户的前端是 angularjs 单页应用程序。问题在于与后端的通信以及保持 Angular 前端与后端数据同步。

后端保存着所有的资源和它们之间的关系，这是显而易见的。前端获取这些资源并在本地保留它们的副本，以使界面对用户响应更快，并避免在每次请求时都获取数据。这太棒了。

服务器端有很多操作同时影响很多资源。这意味着添加/删除/编辑一个资源(通过 REST api)可以修改很多其他资源。

我希望前端应用数据始终与后端数据完全同步。这使我能够保持数据完整性并保持我的应用程序无错误。任何一种去同步化都是一个很大的“不行不行”，它会在我的前端应用程序中引入数百个可能发生未定义行为的地方。

问题是:实现该目标的最佳方法是什么？我的想法/见解:

1. 业务逻辑(修改/编辑/删除资源、管理关系、保持数据完整性)只能执行一次。将业务逻辑实现加倍(一个在前端，一个在后端)会引入很多潜在的错误并涉及代码重复，这显然是一件坏事。如果业务逻辑在前端实现，后端仍然必须验证数据并保持其完整性——业务逻辑的重复。因此，业务逻辑必须在后端。

2. 我使用 REST API。当我的前端更新一个资源(或通过 PATCH 方法更新许多资源)时，服务器端会发生很多副作用，其他资源也会被修改。我希望我的前端 Angular 应用程序知道哪些资源被修改并更新它们(以保持完全同步)。 REST 仅返回最初请求更新的资源，不返回其他受影响的资源。

我知道我可以使用某种形式的链接资源，并发送我的原始更新资源以及指向其他受影响资源的链接。但是如果有 100 个呢？向服务器发出 100 个请求是对性能的彻底扼杀。

1. 我不太喜欢 REST，因为我的 API 不是公开的，它可以是任何东西。我认为最好的解决方案是后端发回所有修改过的资源。这将使我的前端始终与后端同步，速度很快并且是原子的(在对服务器的多个请求之间没有无效的中间状态)。我认为这种架构会很棒。问题是:这是一种常见的方法吗？是否有任何协议(protocol)/标准/库允许我这样做？我们可以从头开始编写它，但我们不想重新发明轮子。

2. 实际上，我认为在前端和后端都有业务逻辑会很好，但前提是要实现一次。这意味着 Javascript 后端应用程序。不幸的是，目前这对我来说不是可行的解决方案。

欢迎任何见解!

添加了 backbone.js 标签，因为问题更多的是关于架构而不是任何特定技术。

Answer 1

您走在正确的轨道上，这是您目前面临的一个常见问题。正如您所说，在 REST 世界中，您的 API 返回请求的/更改的资源。您的问题的一个简单示例:

作为用户 X，您想要关注另一个用户 Y。前端显示您自己的关注计数器 (X) 和其他用户 (Y) 的关注计数器。 http 调用类似于:

PUT /users/X/subscribe/Y

API 将返回用户 Y 资源但 X 丢失，或者相反。

为了处理这种情况，我使用了我的标准 API 响应结构的扩展结构，我的标准结构是:

• 元对象 - 包括 http 状态代码和使用此代码的解释，哪个应用服务器处理了响应等等
• 通知对象 - 包括处理过程中的错误信息(如果有)、开发人员的特殊消息等

• resource - 请求/修改的资源，该属性的名称是单个资源(例如用户)的单数形式或资源集合(例如用户)的复数形式的资源类型

  { 元:{ 状态:200， 消息:“确定”， 应用服务器:app3 }, 通知: { 错误:[] }, 用户:{ 编号:3123212， 订户:123， 订阅数:3234 }

为了也返回其他受影响的资源并保持 REST 方式 + 我的静态标准响应结构，我将另一个对象附加到名为“affectedResources”的响应，它是所有其他受影响资源的数组。在这个非常简单的示例中，数组将只包含用户 X 资源对象。前端迭代数组并在前端处理所有必要的更改。