【问题标题】:Microservices APIs URL pattern微服务 API URL 模式
【发布时间】:2021-01-27 14:31:49
【问题描述】:

我想知道为微服务设计 API 调用 URL 的标准方法。 我有 2 个微服务示例 - 用户、订单。创建的 API 将用于我的应用程序 UI 以及任何第三方集成。 我应该遵循哪种 Url 模式:

方法1:隐藏内部微服务实现

  • 创建用户:

    POST: /user (调用用户服务)

  • 获取用户:

    GET: /user/{userId} (调用到用户服务)

  • 为用户创建订单

    POST: /user/{userId}/order (调用转到订单服务,订单服务在内部使用用户服务验证用户)

  • 通过id获取用户订单

    GET: /user/{userId}/order/{orderId} (调用转到订单服务,订单服务在内部使用用户服务验证用户)

METHOD2:每个 API 都有它属于哪个微服务的详细信息

  • 创建用户:

    POST: /userService/user (调用到用户服务)

  • 获取用户:

    GET: /userService/user/{userId} (调用到用户服务)

  • 为用户创建订单

    POST: /orderService/order (使用请求正文中的 userId 调用订单服务,订单服务在内部使用用户服务验证用户)

  • 通过id获取用户订单

    GET: /orderService/order/{orderId} (调用请求正文中带有 userId 的订单服务,订单服务在内部使用用户服务验证用户) p>

哪一个是好的方法,如果这可以用任何其他不同的方式完成,请告诉我? 提前致谢。

【问题讨论】:

  • POST /user 是单数,表示只能有一个用户。但你的情况并非如此。因此,它必须是 POST /users,对于其他 RESTful 资源也是如此。

标签: api url microservices request-mapping


【解决方案1】:

方法1。从外面看,客户端应该看不到微服务架构和单体架构的区别。

出于安全原因,您不想向外界透露后端的详细信息。

但是话虽如此,如果您正确设计了微服务,每个微服务都会处理特定的资源(用户、订单)。所以看起来每个主路由都针对相应的微服务。

对于完全不同的解决方案,请查看 graphql 和 apollo federation。我使用它来将我所有的微服务 API 包装到一个干净的端点。

【讨论】:

  • 谢谢,如果有任何疑问,我会调查并回复您。
  • 如果你坐在反向代理或 API 网关后面,没有人能够知道它们是由单体还是微服务提供的。这样服务的名称就不会暴露任何“后端的详细信息”,您也不必担心安全方面的问题。
猜你喜欢
  • 2018-01-25
  • 2018-12-04
  • 2021-11-01
  • 1970-01-01
  • 1970-01-01
  • 2019-02-27
  • 2021-04-21
  • 2020-05-05
相关资源
最近更新 更多