您如何命名相同微服务但具有不同消费者的 API 路径答案

【问题标题】：How do you name API paths of the same microservice but w/ different consumers您如何命名相同微服务但具有不同消费者的 API 路径
【发布时间】：2021-11-08 02:31:35
【问题描述】：

上下文

让我们想象一个简单的微服务架构（例如 2-3 个微服务）。微服务是基于域的，API 网关到位，一切都应该是这样。同时，微服务 API 被公共移动应用程序、管理 UI 和其他用于 S2S 通信的服务使用，因此，我们有三个可能的 API 消费者。取决于消费者，响应 DTO 不同，但业务流程可能相同（例如 GET /users 端点的响应对于消费者应用程序和管理 UI 具有不同的 DTO，但从技术上讲，数据是取自同一个数据库）。

问题

在这种情况下，您如何细分 API？您是否使用 external、internal 等命名空间？

此外，请随时分享您在如何细分 API 方面的经验。

提前致谢！

【问题讨论】：

同意下面的@JArgente - 不同的结果应该会引导您走向不同的端点。您当然可以使用相同的端点并使用查询参数或请求标头来区分，但这意味着相同的端点使用多个版本的逻辑。多个端点共享一些核心逻辑是一种很好的模式，使用大量逻辑版本的少数端点似乎不那么明确。

标签： api rest architecture microservices api-design

【解决方案1】：

这在一定程度上取决于您想要采用的理念。

@JArgente 建议的那个很好，因为你会得到很好的分离，并且每个角色的角色（或至少应该）非常清楚。

另一种方法是分层，它（对于 OO 程序员而言）有点像为方法开发重载。它假定派生 API 所需的数据由基础 API 提供。所以：

开发一个基础 API，提供该 API 系列需要提供的所有数据。此 API 可能是内部用户（例如管理员用户）使用的 API，并且可能需要身份验证。
开发一个使用基本 API 的面向公众的 API。这一个将是您面向公众的一个。

每个 API 都有一个单独的 API Spec；根据您的操作方式，您可以在规范级别 leverage inheritance。
每个 API 也有一个触发某种处理的实际端点 - 例如。 API 网关本身内的逻辑，或在下游组件（如微服务）内处理的逻辑。
只要某些东西（例如 API 网关）可以使用某种“服务帐户”对基本 API 进行经过身份验证的调用，面向公众的接口可以是匿名的。

这里的好处是您仍然可以很好地分离不同的 API 及其使用者，但您也可以获得继承的好处，从而减少代码重复（测试工作不那么分散，等等）。

此方法还允许您在同一个 API 网关上运行端点，或部署在不同的端点上（内部与外部）。

【讨论】：

【解决方案2】：

在我看来，API 应该根据使用它们的消费者类型而有所不同。

例如，在谈论您的用例时，它不可能是旨在提供简单用户信息的 API 与管理员使用的 API 相同。在这种情况下，您应该定义两个不同的 API，如您所说，具有不同的路径，如 internal/users/ 和 external/users，并且在内部这两个端点可以使用相同的逻辑。

这种分离不仅有利于在每个端点返回不同的 dto，而且还可以为每个 API 定义不同的安全（身份验证/授权）机制，因为我认为这些要求对于管理 API 和一般的 API 会有所不同用户一

【讨论】：