嵌套资源和微服务：如何避免单体应用？

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 检索个人地址。