微服务中的API设计

Question

我正在设计一个微服务应用程序，但是在REST API设计上遇到了一些困难。

方案：具有服务“客户”和“订单”，并遵循“每个服务数据库模式”的微服务应用程序。

客户服务具有基本端点来表示客户资源，例如：

GET /customers，POST /customers，GET /customers/:id等...

问题：如何设计订单服务的端点，以获取属于客户的所有订单？

我考虑过不同的解决方案，但没有一个能让我满意。

1. /customers/id/orders-我的解决方案问题是在不包含任何有关客户数据的服务中使用“客户”。

2. /orders?customerid=123-可以，但是我不认为它遵循正常的API设计准则。

在微服务架构中是否存在关于API设计主题的指南？

Answer 1

IMO，您正在请求订单，因此您应该要求提供资源订单。您是客户，因为订单没有保存在客户资源中，因此您没有任何角色。 如果有的话，订单可以参考客户。 而且，如果您要基于某些属性查询订单，则应将它们作为查询参数传递。 因此，由于您要向（GET）索取资源（Order）并希望对其进行过滤（基于查询参数中的客户），因此选项2很有意义。 那就是我将如何设计它，这就是我以这种方式设计它的原因。