嵌套资源和微服务:如何避免单体架构?

Question

我想检索一个人的地址详细信息。

根据 REST 规范，我必须具有以下路径：

GET /person/<person id>/address/<address id>

现在，假设我想检索电子地址，我将有：

GET /person/<person id>/address/<address id>/electronic/<elec id>

等等。 虽然 REST 方面很好，但它可能会导致整体方法，因为 openapi 生成器(以及实现它的人)将创建一个单独的微服务来处理多种数据。

处理这种情况的另一种方法是什么？ 我在想：

1-反转逻辑

GET /addresses/<person id>/<address id>
GET /electronicAddresses/<person id>/<address id>/<electronic address>

2-使用标头/查询字符串参数并留给单个服务

GET /addresses/<address id>?person_id=
GET /electronicAddress/<elec id>?person_id

我可以有一些实用的方向吗？我觉得内在资源方法最终会爆炸......

Answer 1

如果我理解正确，您希望分解您的 API 并将其映射到微服务架构，就像address和person的情况一样。

如果是这样，请考虑address和person如何独立，因此将有两种服务：Person service和Address service.哪个将有下一个 API：

GET /persons/{person_id}
GET /addresses/{address_id}

现在的问题是，如何获取某人的地址，因为所有地址API都没有与任何人相关的请求参数。答案是：进行两次 API 调用。

因此，在第一个请求中，客户端通过person_id检索人员数据，其中应包含对地址实体的一些引用，例如：address_id。现在使用第二个请求，客户端可以通过从个人数据中解析address_id来检索人员地址。