微服务设计中的 API 命名答案

【问题标题】：Api naming in microservices design微服务设计中的 API 命名
【发布时间】：2016-02-16 04:46:45
【问题描述】：

假设有两个微服务分别代表资源订单（/orders）和客户（/customers）。我的要求是获得客户的所有订单。如果它是一个单体应用程序，我会将我的 uri 建模为 /customers/{id}/orders。这会影响客户资源并进行内存服务调用以获取相应的订单。现在，对于微服务，这是不可能的。那么，获得订单的唯一方法是进行远程服务调用还是有更好的方法呢？我们可以创建另一个具有 /ordersByCustomers/{customerid} 表示的资源吗？

【问题讨论】：

您可能想要查看HATEOAS，您可能想要阅读How do I ask a good question，这会提高大大获得有用答案的可能性。你可能会发现ESR 的优秀文章How To s The Smart Way 很有帮助。
其实我觉得这是一个很好的、有趣的问题，但对于程序员 stackexchange 而不是 stackoverflow 部分来说可能更多的东西。虽然 HATEOAS 无论如何都很有趣
@Markus W Mahlberg：请不要再做一个彻头彻尾的混蛋了。
@AlexanderTorstling 我知道标题听起来很粗鲁，但这篇文章确实值得一读——即使对于最有经验的人也是如此。很少有人写出如此真实的文字。试试吧。 ;)

标签： rest microservices

【解决方案1】：

您可以将一些查询参数作为过滤器传递（这是我见过的最常见的方式）。例如

/orders?customerId=123

我认为这很清楚，您要检索按客户 ID 过滤的所有客户订单。以同样的方式，您可以添加分页或其他过滤器。

要记住的重要一点是您需要 order 资源，因此 URL 应该保持不变。我之所以提到这一点，是因为这对我来说是最难改变的……考虑资源而不是远程调用。

【讨论】：

这是有道理的，但是过滤器的问题在于它使资源更加通用，如果有更多的查询参数，逻辑也可能变得更加复杂。此外，客户本身就是一个适当的资源，其中将它作为查询参数仍然正确吗？
我认为客户和订单都是独立资源，它们是相互关联的（我认为从系统的角度来看这是一个非常重要的方面）。如果你想删除一个客户，你也想删除他们的订单吗？（以及这可能对您的财务系统产生的所有影响？）。对于类似的阅读，我认为这与aggregation vs composition 中的问题相同。这也与Bounded Context的领域驱动设计理念相辅相成

【解决方案2】：

一般来说，您应该注意使用与您建议的端点或多或少相似的端点：

/ordersByCustomers/{customerid}

为什么？因为这在一般情况下不是 RESTful（即使在微服务环境中），并且使 API 难以被消费者和您理解。如果你需要orderByWhatever怎么办？您是否会在每次需要一组新数据时引入新端点？尽量避免如此自以为是的端点。

@Augutsto 的建议是完全正确的。如果您害怕在GET 请求中有复杂的逻辑，这就是您可以破坏 REST 规则的情况。我的意思是介绍：

POST /orders/filter/

所有过滤逻辑都将在请求正文中传递 - 因此也更容易携带复杂的逻辑。

【讨论】：