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

【问题标题】：Should web api for placing order also handle user creation?用于下订单的 web api 是否也应该处理用户创建？
【发布时间】：2015-06-23 08:13:43
【问题描述】：

我有一个用于网上商店的 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 是否有一些通用标准？

【问题讨论】：

【解决方案1】：

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

缺点：

有什么标准吗？基本上不，REST 不是一种标准，而是一种架构风格。但是，如果您交付的 API 将被多个客户端使用，您应该尽可能地遵守 REST 规则，除非您有充分的理由遵守这些规则。我在这里看不到这样的借口。

【讨论】：