使用 REST API 将数据库与其他 REST API 解耦答案

【问题标题】：Using REST API to decouple database from other REST APIs使用 REST API 将数据库与其他 REST API 解耦
【发布时间】：2020-03-11 19:15:37
【问题描述】：

我在措辞上遇到了一些问题，但基本上，我发现在我工作的地方创建一个连接到数据库的 Java Spring Rest API 并且前端应用程序使用该 API（web-app ->服务 API -> 数据库）。这将应用程序服务 API 耦合到数据存储，并且通常是前端应用程序的特定用例。我看到许多服务 API 创建对同一个数据库的相同 get 调用。这对我来说似乎是错误的。

我相信为数据库本身创建一个 API，然后运行服务 API 会更好。（网络应用程序 -> 服务 API -> 数据存储 API -> 数据库）。这将允许所有服务访问数据库，而无需直接耦合到数据库，并且必须为 30 个应用程序管理对该数据库的访问。它还允许任何除了数据之外不需要任何东西的应用程序只使用现有的数据存储 API。我记得一篇关于亚马逊如何要求每个数据存储都有一个 API 的文章，这就是我看到的处理方式。

拥有数据存储 API 并使用服务 API 连接到该 API 的想法是否正确？还是我应该用其他方法来处理这个问题？

【问题讨论】：

解耦很好，但这取决于您的详细信息。我认为再添加一个 API（“胶水”）会引入复杂性。如果您通过 Rest API 和一些 API 密钥公开您的数据，那还不够好吗？多一个 API 就是另一件可能出错的事情……你可能想加入另一个 API，但不强迫每个人都使用它。这是架构师的架构决策。
作为背景：我们有一个带有阿尔伯斯坐标的系统。不是每次我们访问的每个资产都转换为 gps，而是有 4 个项目，每个项目获取他们需要访问的每个对象（例如所有计算机或所有路由器）的坐标，并将它们与 gps 坐标一起存储在数据库中以供其应用程序使用。有一个 api 来访问该数据库并选择作为 gps 检索不是更好吗？这样可以在需要时拉取而不是存储4次？

标签： java spring database rest api

【解决方案1】：

阅读您刚刚写的内容，在我看来，您所拥有的是“微服务做错了”，因为我可以理解您有几个应用程序访问同一个数据库/数据存储，从微服务的角度来看这是错误的。

如果任何应用程序需要查询/更新其他应用程序的数据，它使用 API 而不是直接访问数据库，则每个应用程序都应将其自己的数据库划分为边界。

底线是，每个应用程序不应使用 API 来访问单个数据库，而应将自己限制在自己的边界内并访问自己的数据库。

当然，一种尺寸并不适合所有人，但我相信这是一个很好的指南。

【讨论】：

我认为重复数据很糟糕。拥有 4 个具有相同数据的数据存储不会浪费吗？例如，我们有一份公司正在使用的设备列表。为什么我们想要该列表的 4 个重复项？我们需要源数据库来提供所有这些，不是吗？
我想你误会了，我从来没有打算让数据全部复制，而是将其划分为边界，每个应用程序都对其边界负责，仅此而已。如果另一个应用程序需要这些数据，您向该应用程序请求您永远不会直接访问其数据库。