Question

我正在阅读一些关于使用rest服务正确使用URI的文档，我遇到了一个基本GET .. DELETE请求的例子。

示例uri是：

获取所有用户

GET http://mydomain.org/api/users

获取特定用户

GET http://mydomain.org/api/users/1

更新用户

PUT http://mydomain.org/api/users/1

删除用户

DELETE http://mydomain.org/api/users/1

用户资源可以是以下形式的JSON或XML：

{
    Id: 1,
    FirstName: 'John',
    LastName: 'Doe'
}

我的问题是这个。要维护REST原则，是否需要在PUT请求的URI中包含资源的ID？

Answer 1

PUT方法请求创建目标资源的状态，或者用请求消息有效负载中包含的表示定义的状态替换目标资源的状态。

您希望将PUT资源发送到您想要GET的相同URI。

RFC 72314.3.4 PUT

Answer 2

我打算问一个类似的问题，但我想我找到了答案。我不确定它是否属于REST原则，但这就是为什么不在URI中包含ID会很糟糕。所以说你的PUT就像：

PUT http://mydomain.org/api/users

然后您碰巧更新了具有不同ID的多个用户，但是相同的URI导致您的URI中没有ID。然后，重要的是要知道PUT是幂等的http动词。这意味着调用它应该具有与多次调用它相同的效果。因此，网络中的某个中间节点，只要遵循您多次PUT的事实，可能会忽略除一个请求之外的所有节点，因为它们具有相同的URI。最后，这不是你想要的，因为目的是更新多个用户而不仅仅是一个。

Answer 3

PUT http://example.com/api/users + body的行为类似于带有键http://example.com/api/users和值body的地图的放置。如果不存在，则会创建一个新条目，否则将覆盖现有条目。

问题：http://example.com/api/users背后的资源是什么？

答案：与GET http://example.com/api/users（所有用户的列表）提供的答案相同。

因此，命令PUT http://example.com/api/users表示您将所有用户的列表替换为您提供的用户。

为了保持一致，正文应包含一组用户：

[
  {
    Id: 1,
    FirstName: 'John',
    LastName: 'Doe'
  },
  {
    Id: 2,
    FirstName: 'Albert',
    LastName: 'Einstein'
  }
]

Answer 4

在放置请求的 URL 中包含 id 的另一个好处是 CREATE/UPDATE 函数可以共享一些逻辑。

假设您有一个包含 3 列的用户表。

id(primary key, auto increment) | name | age

创建用户将生成一个 ID。

POST /users
{
  name: "foo"
  age: 25
}
-> generate id 123

因为 id 在 URL 中，所以您可以使用相同的请求正文结构来更新用户。

PUT /users/123
{
  name: "bar"
  age: 25
}

这可能与 REST 主体关系不大，但它可以根据您的语言/框架在实践中简化请求处理的代码。

在PUT请求的URI中包含Id

4 个答案: