用于下订单的web api是否也应该处理用户创建？

Question

我有一个用于网络商店的API。该API有一些消费者，他们有可能创建用户并下订单。 其中一位消费者建议合并两个api电话，让我们说/user/create和/order/create合二为一。 由此：

POST /user/create {name: 'John', email: 'john@example.org'}

POST /order/create {basket: [...], user_id: 12938}

对此：

POST /order/create 
{
    user: {name: 'John', email: 'john@example.org'}, 
    basket: [...]
}

在我看来，这会降低灵活性并增加处理错误的复杂性（例如，如果此类电子邮件已存在）

解决方案的优点/缺点是什么？这种API有一些共同的标准吗？

Answer 1

基本上，我认为没有这种架构错误的优点，除了单一的 - 客户端的逻辑会更简单，因为它只发送一个查询并且不关心。但这也是一种短视 - 客户将不得不处理不同的错误。

缺点：

• 这些是完全不同的资源 - 应该分开。
• 更难测试 - 您需要处理各种测试场景。很容易忽视一个。
• 异常和HTTP代码怎么样？订单已发送，您已收到电子邮件错误 - WTF？应该有什么状态代码？
• 这种解决方案可能只适合单个客户的其他内容吗？

有没有标准？基本上不，REST不是标准，而是建筑风格。但是，如果您提供将由多个客户端使用的API，则应尽可能遵守REST规则，除非您有充分理由遵守这些规则。我在这里没有看到这样的借口。