使用API替代直接访问数据库的优缺点

Question

我发现在本周的几次讨论中，人们谈到了一个正在开发中的Web应用程序是否应该利用正在创建的API。

情况是这样的：我有一个使用MySQL DB的PHP MVC Web应用程序，还有几个移动应用程序正在内部开发。对于移动应用程序，我们正在构建一个REST API。重要的问题是，为什么我的PHP Web应用程序现在要使用那个REST API呢？我一直认为API的使用是为第三方系统与我的数据库进行接口交互或者为使用不同技术构建的系统服务。Web应用程序肯定不是第三方系统，而且服务都是使用PHP编写的。如果API位于不同的服务器上，则可以将其视为第三方系统...但这尚未决定。

对我来说，似乎很奇怪为Web应用程序利用API，特别是由于API的服务将仅限于Web应用程序中50％的功能，而另外50％则是独特于Web应用程序的。我还预见到通过服务层步进而不是直接访问数据库，Web应用程序会受到性能影响。另一方面，我看到维护代码库以使Web应用程序访问数据库和类似函数内置于移动应用程序的API方便得多。

是否有人遇到过类似的情况，并可以提供一些技术上的优缺点，说明为什么我应该使用API，或者可以指向一个可靠的案例研究？

- Runicode

---

如果有帮助的话，当我编写 PHP 应用程序时，我会创建应用程序将使用的服务（例如与数据库中的产品交互的服务），这些服务在内部直接使用 (app()->service->doSomething())，只需要在顶部添加一个薄层，以便将功能公开为 HTTP API。 - Marty

API必须访问数据库，不是吗？所以无论如何，您仍然在查询数据库。如果API位于单独的服务器上，我肯定会反对它，因为它会使用该服务器的资源而不是使用自己的资源。 - user5236938

Answer 1

优点：

• 如果有一天你决定将后端应用程序移动到另一台机器上？使用API，你的应用程序代码不需要更改。
• 如果有一天你发展壮大，需要扩展到10000个后端应用而不是1个？使用API，你的应用程序代码不需要更改。
• 如果有一天你决定将MySQL换成Mongo？使用API，你的应用程序代码不需要更改。
• ^ 数据访问层（数据库）和应用程序之间强制实行关注点分离

缺点：

• 编写应用程序层时需要更多的代码。
• 当你需要支持一个API尚未支持的新的应用程序层功能时，需要进行更多的增量工作。

对我来说，优点显然胜过缺点。

- bcherny

---

延迟增加不是另一个缺点吗？ - herteladrian

使用API方法，如果您使用MVC结构，则还会失去ORM的潜在好处。您可以使用类似GraphQL的东西来达到相同的易用性，但是很少有框架具有这种行为。优点是，通过API和基础架构分离，您距离微服务架构更近了一步。 - Kalle