Php 使用API代替直接数据库访问的利弊

我发现自己参加了一周中的几次讨论，讨论的内容涉及正在开发的web应用程序以及它是否应该利用正在创建的API

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

对我来说，在web应用程序中使用API似乎很奇怪，特别是因为API服务将被限制在web应用程序中可用功能的50%左右，而剩下的50%是web应用程序特有的。我还预见到web应用程序通过服务层而不仅仅是直接访问数据库会受到性能影响。另一方面，我看到了更多的维护，我的web应用程序的代码库可以访问DB，类似的功能也可以内置到移动应用程序的api中

是否有人发现自己处于类似的情况，并能提供一些技术上的利弊，说明我为什么应该只使用API，或者可以为我提供一个可靠的案例研究？

优点：

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

缺点：

• 编写应用程序层时，请提前编写更多代码
• 当您需要支持API尚不支持的新应用程序层功能时，需要进行更多增量工作

---

对我来说，专业人士显然是赢家。

如果有帮助，当我编写PHP应用程序时，我会创建应用程序将使用的服务（例如，与数据库中的产品交互的服务），这些服务直接在内部使用（

app（）->service->doSomething（）

）如果功能需要通过HTTP以API的形式公开，那么只需要在上面加一层薄薄的层。API必须访问数据库，不是吗？因此，无论采用哪种方式，您仍在查询数据库。如果API位于单独的服务器上，我肯定会反对它，因为它使用该服务器资源，而不是使用自己的资源？