使用单个POST更新请求创建两个对象坏API设计？

考虑这个场景，一个未知的未经身份验证的用户正在查看nerddinner列表，然后去参加一个特定的晚宴，输入他的姓名和电子邮件，然后单击“出席”。这将导致两件事。创建用户并为该用户创建请求。 用户还有一个名为FavProgLanguage的属性，该属性设置为他想要参加的晚宴的prog language属性

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

1） 在客户端上，设置用户FavProgLanguage，然后使用名称、电子邮件和FavProgLanguage发布到/user以创建用户。使用创建的UserId和POST to/dinneratendrequest以及DinnerId和UserId创建dinneratendrequest

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

第一种方法看起来更自然/RESTful，但是如果favproglanguage的计算逻辑有点复杂，那么所有api使用者都必须实现该逻辑，而第二种方法只需在服务器上编写一次代码

---

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

您的第一种设计将把逻辑、工作流程和fav lang决策的负担交给客户机，这将使处理用户创建和预订成为一个单一事务变得困难，客户机应用程序需要协调。您的fav-lang逻辑听起来像是一条重要的业务规则，最好还是放在服务器上重复使用

你为什么不考虑拥有这样的资源：

晚餐，如{“姓名”、“日期”等]

预订，例如{“用户”{嵌套用户资源}，“预订状态”等}

用户，例如：{“电子邮件”、“姓名”、“fav lang”等}

一些示例URL

/晚餐/{uid}

/晚餐/{uid}/预订

/用户/{uid}

基本上，我会将包含嵌套用户资源的预订资源发布到晚餐预订url，并运行逻辑来检查是否存在用户，如果需要，创建并更新事务中的fav lang

因此，要创建预订，我将发布预订资源：

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

到/晚餐/{uid}/预订

并期望一个201创建的响应具有如下响应：

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

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