1

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

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

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

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

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

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

4

1 回答 1

3

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

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

  1. 晚餐例如{“姓名”、“日期”等}
  2. 预订例如 { "user" { NESTED USER RESOURCE }, "bookingStatus" 等 }
  3. 用户 eg { "email", "name", "fav lang", etc.}

一些示例网址

  1. /晚餐/{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 ......

于 2012-09-14T08:06:06.747 回答