我们有一个简单的电子商务网站，我们有几个产品。目前，每个产品都有"下订单"按钮。
当用户单击此按钮时，我们会向用户显示一个表格以填写姓名，手机号码和地址。我们不支持任何货币交易。用户填写此表单后，订单将保存到数据库中。订单表具有订单ID，产品ID，用户名，用户移动。
我们正在设计API来保存用户订单。在设计这个时，我们是否应该有关联的黑白产品和订单？
例如，保存用户订单的 URI 应该是这样的：
- POST/api/products/1/lead/- 请求正文包含用户信息，即姓名，手机，地址。或
- POST/api/lead/- 请求正文包含"产品ID"和用户信息，即姓名，手机，地址。
我很困惑产品 ID 应该在请求 URI 中还是在请求正文中？我们如何做出这样的决定？
鉴于
- 您首先导航到产品，然后再实际下订单
- 产品 ID 与您发布的
UserInformation模型没有任何共同之处
我会选择第一个选项：POST /api/products/1/lead/
为了简单起见，我总是会使用更浅的路线来表示资源。不，嵌套路由并不复杂或任何东西，但我见过嵌套走得很远。所以我会让它尽可能浅，除非...
1(你计划拥有不止一件可以有线索的事情。例如，您可以拥有产品的潜在顾客：
api/products/1/lead
或你们都提供的托管服务的潜在客户或其他东西(我现在正在联系(：
api/managed_services/2/lead
你可以总是在正文中传递这些信息，但我想根据 json 中定义的属性来创建什么资源会变得有点麻烦。
2(你计划打破这条路线，并让它最终去不同的服务。也许这个应用程序将不得不大幅扩展，并且大量用户将比系统中的任何其他端点更多地遇到这条路线。根据以api/products开头的 url 将所有请求重定向到不同的微服务比基于请求正文重定向要容易得多。
但老实说，我认为这并不重要。只要您的客户易于使用。