我有一个用户微服务。此微服务使用token authorization.现在它被 Web 应用程序使用。工作流如下所示：
- 用户使用
AzureAd OpenIdConnect登录 Web 应用程序; - Web 应用程序接收
access token(authorization code流(; - Web 应用程序从用户服务获取用户详细信息，在 HTTP 请求标头中传递
access token。
此外，我有一个守护程序微服务，我没有用户上下文。我也想允许这个守护程序服务从用户服务中获取用户详细信息。在这种情况下，我将使用client credentials流。
如何正确组织用户服务 rest api？
我正在考虑这种方法：
- 用户的数据可在此 URL
/users/{userId}/info; - 具有用户上下文的应用程序(即使用
authorization codeFlow 为特定用户颁发访问令牌(只能为current user使用数据，或者current user是管理员并且可以处理其他用户的数据; - 没有
current user的守护程序应用程序(即访问令牌是使用client credentials流为应用程序本身颁发的(可以为任何用户读取数据。
此类案例的最佳实践是什么？
我认为定义此 API 的最佳和更宁静的方法是构建一个唯一的端点/users/{id}。 其中 id 可以是实际的真实用户 ID 或预定义的值，如"me"。它是用户服务，如果 id 值为"me"，则必须从令牌中检索用户信息。 我要做的其他更改是使用users而不是user因为其余的良好做法表明 URL 中的元素是集合。 最后一个，不使用info，因为它是多余的。因为当您查询一个实体时，显然您想要它的信息