使用单个 POST 请求进行更新以创建两个对象 糟糕的 API 设计？

Question

考虑这种情况，一个未知的未经身份验证的用户正在查看 nerddinners 列表，然后去参加特定的晚餐，输入他的姓名和电子邮件，然后单击“参加”。这应该导致两件事。创建用户并为该用户创建 DinnerAttendRequest。 用户还有一个名为 FavProgLanguage 的属性，该属性设置为他想参加的晚餐的 prog 语言属性。

假设它是一个与 API 对话的单页 javascript 应用程序，我想到了两种方法。

1) 在客户端上，设置用户 FavProgLanguage，然后使用名称、电子邮件和 favproglanguage POST 到 /user 以创建用户。使用创建的 UserId 和 POST 到 /DinnerAttendRequest 以及 DinnerId 和 UserId 来创建 DinnerAttendRequest。

2) 使用名称、电子邮件和晚餐 ID 发布到 /somename，然后在服务器上使用晚餐 ID 填充用户的 favproglanguage。创建用户，然后使用用户 ID 创建 DinnerAttendRequest

第一种方法似乎更自然/RESTful，但是如果计算 favprog 语言的逻辑有点复杂，所有 api 使用者都必须实现该逻辑，而第二种方法只在服务器上编写一次代码。

哪种方法更好？第二种方法是 RESTful 的吗？

Answer 1

您的第一个设计会将逻辑、工作流程和偏好语言决策的负担放在客户端身上，这会使处理用户创建和预订成为一项困难的事务，并且需要客户端应用程序来协调。您最喜欢的语言逻辑听起来像是一个重要的业务规则，理想情况下应该再次位于服务器上以供重用......

你为什么不看看有一些像这样的资源：

1. 晚餐{ “姓名”、“日期”等 }
2. 预订，例如{ "user" { NESTED USER RESOURCE }、"bookingStatus" 等 }
3. 用户例如{“电子邮件”、“姓名”、“喜欢的语言”等}

一些示例网址

1. /dinners/{uid}
2. /dinners/{uid}/bookings
3. /users/{uid}

基本上，我会将包含嵌套用户资源的预订资源发布到晚餐预订网址并运行逻辑以检查用户是否存在，如果需要创建并在事务中更新他们的最爱语言。

所以要创建预订，我会发布预订资源：

{
    "user": {
        "email": "john@doe.com",
        "name": "name"
    },
    "bookingStatus": "requested"
}

到 /dinners/{uid}/bookings

并期望创建 201 响应，响应如下：

{
    "uid": "4564654",
    "user": {
        "uid": "1234564",
        "email": "john@doe.com",
        "name": "name",
        "favLang": "C#"
    },
    "bookingStatus": "booked"
}

显然，这些属性主要只是举例，但希望这能展示一些概念并表明单个 POST 可以被视为 RESTful...