使用 API 而不是直接 DB Access 的优缺点

Run*_*ode 3 php api rest

我发现自己整个星期都在讨论正在开发的 Web 应用程序以及它是否应该利用正在创建的 API。

这是情况。我有一个带有 MySQL 数据库的 PHP MVC Web 应用程序以及几个内部开发的移动应用程序。对于移动应用程序,我们正在构建一个 rest api。最大的问题是为什么我的 PHP Web 应用程序现在应该使用那个 rest api?我一直希望 API 用于需要与我的数据库连接的第三方系统或基于不同技术构建的系统。Web 应用程序当然不是第三方系统,并且服务是用 PHP 编写的。如果 API 与 Web 应用程序位于不同的服务器上,那么我想它可以被视为第三方系统......尚未确定。

对我来说,利用 Web 应用程序的 API 似乎很奇怪,尤其是因为 API 服务将被限制在 Web 应用程序中可用功能的 50% 左右,而我要构建另外 50% 的功能网络应用程序。我还预见到通过服务层而不是直接访问数据库对 Web 应用程序的性能造成影响。另一方面,我看到更多的维护工作为我的 Web 应用程序提供了一个代码库,这些代码库可以访问数据库,并且类似的功能内置于移动应用程序的 api 中。

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

bch*_*rny 7

优点:

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

缺点:

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

对我来说,职业选手显然赢了。

  • 延迟增加不是另一个缺点吗? (7认同)