REST API设计：我们何时应该在Uri中使用关联来获取资源？

Question

我们有简单的电子商务网站，我们有几个产品。目前，每个产品都有＆＃34;下订单＆＃34;按钮。

当用户点击此按钮时，我们会向用户显示一个表单，以填写姓名，手机号码和地址。我们不支持任何货币交易。用户填写此表单后，订单将保存到数据库中。订单表包含OrderId，ProductId，UserName，UserMobile。

我们正在设计API以保存用户订单。在设计时我们应该有关联的黑白产品和订单吗？

例如，保存用户订单的URI应该是：

1. POST / api / products / 1 / lead / - 请求正文包含用户信息，即姓名，移动电话，地址。 OR
2. POST / api / lead / - 请求正文具有＆＃34; PRODUCT ID＆＃34;和用户信息，即姓名，手机，地址。

我很困惑productId应该在请求URI中还是在请求体中？我们如何做出这样的决定？

Answer 1

鉴于此

• 您在实际下订单之前首先导航到产品
• 产品ID与您发布的UserInformation型号没有任何共同之处

我选择了第一个选项：POST /api/products/1/lead/

Answer 2

为了简单起见，我总是采用更浅的方式来表示资源。不，嵌套路线并不复杂或任何东西，但我看到嵌套走得很远。所以我会尽量保持浅薄，除非......

1）你计划有多个可以带头的东西。例如，您可以在产品上占据领先地位：

api/products/1/lead

或您所提供的托管服务的主管或某事（我现在就到达）：

api/managed_services/2/lead

你总是可以在身体中传递这些信息，但我想根据json中定义的属性来创建要创建的资源会变得有点麻烦。

2）你计划打破这条路线并最终让它去另一个服务。也许这个应用程序必须大幅度扩展，并且大量用户将比系统中的任何其他端点更多地击中此路由。基于从api/products开始的URL，将所有请求重定向到不同的微服务要比基于请求体的重定向容易得多。

但老实说，我认为这不重要。只要您的客户很容易消费。