如何命名相同的微服务的API路径，但是w/不同的使用者？

Question

上下文

让我们设想一个简单的微服务体系结构(例如，2-3个微服务)。微服务是基于域的，API网关已经就位，一切都是它应该做的.同时，微服务API被公共移动应用程序、管理UI和其他用于S2S通信的服务所消耗，因此，我们有三种可能的API使用者。根据使用者的不同，响应DTO是不同的，但业务流程可能是相同的(例如，对于GET /users端点的响应对于使用者应用程序和管理UI有不同的DTO，但从技术上讲，数据来自同一个DB)。

问题

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

此外，您也可以自由地分享如何分割API的经验。

提前感谢！

Answer 1

在我看来，API应该是不同的，取决于将要使用它们的使用者的类型。

例如，谈到您的用例，它不可能是用于提供管理员使用的简单用户信息的API。在这种情况下，您应该定义两个不同的API，使用不同的路径，比如内部/用户/和外部/用户，并且在内部这两个端点可以使用相同的逻辑。

这种分离不仅有利于在每个端点中返回不同的dtos，而且还可以为每个API定义不同的安全(身份验证/授权)机制，因为我认为对于管理API来说，这些需求与普通用户的不同。

Answer 2

这在一定程度上取决于你想采用的哲学。

@J阿根廷的建议是好的，因为你会得到很好的分离，而且每个人的角色都非常清楚(或者至少应该是这样)。

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

1. 开发一个基本API，提供这个API家族需要提供的所有数据。这个API可能是内部用户使用的API(例如Admin用户)，它可能需要身份验证。
2. 开发一个使用基本API的面向公共的API。这个应该是你面向公众的。

​

​

• 每个API都有一个单独的API；取决于您如何做到这一点，您可以在Spec级别上进行杠杆继承。
• 每个API还有一个实际的端点，它触发某种处理--例如API网关本身内的逻辑，或者在下游组件(如微服务)中处理的逻辑。
• 面向公共的用户可以是匿名的，只要某些东西(例如API网关)可以使用某种“服务帐户”对基本API进行身份验证调用。

这里的优点是您仍然可以很好地分离不同API和它们的使用者，但是您也可以获得继承的优势，这样代码复制就会减少(测试工作不会如此分散，等等)。

这种方法还允许您在同一个API网关上运行端点，或者部署在单独的端点上(内部还是外部)。