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

Posted

技术标签:

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

上下文

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

问题

在这种情况下,您如何细分 API?您是否使用 externalinternal 等命名空间?

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

提前致谢!

【问题讨论】:

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

【讨论】:

以上是关于您如何命名相同微服务但具有不同消费者的 API 路径的主要内容,如果未能解决你的问题,请参考以下文章

如何反序列化具有相同名称但不同类型的 API 响应

具有相同命名空间但在不同程序集中的内部类?

任务消费者微服务架构流程

视频转换后如何命名输出文件与输入文件相同但扩展名不同? [复制]

如何在微服务和API网关架构中对不同的配置文件进行身份验证和授权

微服务项目服务管理混乱?来看这一篇生产者消费者服务实践,使用API网关实现服务聚合