使用 API 代替直接 DB 访问的优缺点

Question

我发现自己在一周内多次讨论正在开发的 Web 应用程序以及它是否应该利用正在创建的 API。

情况是这样的。我有一个带有 MySQL DB 的 PHP MVC Web 应用程序以及几个正在内部开发的移动应用程序。对于移动应用程序，我们正在构建一个 rest api。最大的问题是为什么我的 PHP Web 应用程序现在应该使用那个 rest api？我一直希望 API 用于需要与我的数据库交互的第三方系统或基于不同技术构建的系统。 Web 应用程序当然不是第三方系统，服务使用 PHP。如果 API 与 Web 应用程序位于不同的服务器上，那么我猜它可能被视为第三方系统......这还没有决定。

对我来说，将 API 用于 Web 应用程序似乎很奇怪，特别是因为 API 服务将被限制在 Web 应用程序中可用功能的 50% 左右，让我构建另外 50% 的功能对 Web 应用程序来说是独一无二的。我还预见到通过服务层而不是直接访问数据库的 Web 应用程序的性能会受到影响。另一方面，我看到更多的维护工作有一个代码库，用于我的网络应用程序访问数据库，以及内置在移动应用程序 api 中的类似功能。

有没有人发现自己处于类似情况并且可以提供一些技术优缺点来说明为什么我应该只使用 API 或者可以指出一个可靠的案例研究？

Answer 1

优点：

• 如果有一天您决定将后端应用程序移动到另一台计算机上怎么办？ 使用 API，您的应用代码无需更改。
• 如果有一天您发展壮大，需要扩展到 10000 个后端应用程序而不是 1 个怎么办？ 使用 API，您的应用代码无需更改。
• 如果有一天您决定将 MySQL 换成 Mongo，该怎么办？ 使用 API，您的应用代码无需更改。
• ^ 强制分离数据访问层 (DB) 和应用程序之间的关注点

缺点：

• 编写应用层时需要预先添加更多代码
• 当您需要支持您的 API 尚不支持的新应用层功能时，需要进行更多增量工作

在我看来，专业人士显然是赢家。