在通过将 Web 服务引入现有架构或反之亦然来扩展 Web 应用程序时，开发人员是否可以想到一种可能的架构。在这种情况下，主要关注的是数据完整性和安全性。
以下图片将建议开发人员可以想到的两种方法。
该架构表明所有请求都应由单独的服务层处理。因此，只有服务层才能与数据库通信，同时满足Web应用程序和网关的请求。
第二种方法显示 Web 应用程序直接与 DB 通信。例如管理员门户。同时，可以有一个外部 Web 服务也与 DB 进行通信。这种方法可能会导致违反数据完整性的情况。但是，引入外部 Web 服务可能比重构现有 Web 应用程序以从开发人员端调用 Web 服务更容易。因此，我们是否仍然可以通过使用外部 Web 服务和单独的 Web 应用程序而不是 Web 应用程序和网关都使用单个 Web 服务层来满足长期后果。对此的任何合理评论将不胜感激。
您可以构建一个可以访问所有内容的 API。换句话说，Web 应用程序可以通过使用 Ajax/WebSockets 的 rest/rpc api 工作。
由于一切都通过 API，因此不应在任何时候强制执行数据完整性。此外，您将与 Client、Api 和 Database 明确分离。
这将允许您用其他任何东西替换数据库，而不会破坏系统的其他部分。
我不得不在几个项目中回答这个问题；还有一个你没有提到的第三个选项，这是我最喜欢的。
选项 1 -“作为持久性和业务逻辑层的 Web 服务”的问题在于它在设计中引入了许多额外的移动部分。这些移动部件很昂贵——你必须编写、测试和维护更多的代码，而且你想要从你的 Web 服务中运行你自己的应用程序的服务通常对第 3 方开发人员来说并不有意义。您还引入了潜在的重大性能和可伸缩性风险 - 调用调用数据库的 Web 服务比仅调用数据库慢得多。
第二种选择——跨 Web 应用程序和服务层复制业务逻辑——存在所有重复问题。
我更喜欢的选项是将业务逻辑层开发为一个单独的组件，并让 Web 应用程序和 Web 服务都使用它；每个应用程序都将组件用作库。这意味着您必须拥有独立的团队——“库”团队和“应用程序”团队——但避免重复，并且避免每次必须呈现网页时调用一堆 Web 服务。
业务逻辑层负责持久性——包括确保数据库一致性得到尊重，以及管理事务。由于业务逻辑层在 Web 应用程序和 Web 服务之间共享，因此该逻辑被集中到单个代码库中，并且 - 理想情况下 - 对应用程序完全透明。
Web 服务现在做的少得多。他们的工作是处理传入的请求，将它们转换为业务逻辑组件上的方法调用，并以适当的格式（XML、JSON）返回任何响应数据。他们可能会提供“粗粒度”的服务请求，并将它们映射到几个更细粒度的业务逻辑方法上。它们可能处理身份验证、授权、请求限制等。它们只是不处理实际的业务逻辑。
我个人建议至少有一个共享数据访问层来处理数据验证和持久性。
然而，最好的方法是在您的第一个图表中定义，使用共享服务层来分解应在此级别定义的事务管理。您可以利用自定义事务隔离和/或锁定策略来确保数据完整性。在这种情况下，公共服务层方法可以直接公开为休息服务，并由移动和 Web 应用程序使用（不需要网关/API 组件）。
所有这一切都取决于估计的时间来重构遗留应用程序架构并在另一个上复制数据访问逻辑（和业务逻辑？？？）。当然，重复会降低可维护性和可扩展性。