Rest 在URI中包含PUT请求的Id

我正在阅读一些关于使用rest服务适当使用URI的文档，我遇到了一个基本GET的示例。。删除请求

示例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

PUT方法请求创建目标资源的状态，或将其替换为请求消息负载中包含的表示所定义的状态

您希望

将

一个资源放到您希望

从中获取它的同一个URI中

我本想问一个类似的问题，但我想我找到了答案。我不确定这是否符合REST原则，但这就是为什么在URI中不包含ID是不好的。
所以说你的
PUT
是这样的：

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

然后您碰巧用不同的id更新了多个用户，但是相同的URI，因为您的URI中没有id。然后，这里需要知道的一件重要事情是PUT是幂等http动词。这意味着调用一次应该与多次调用具有相同的效果。因此，网络中的某些中间节点可能会忽略除一个请求外的所有请求，因为它们具有相同的URI，而只是遵循您多次放置的事实。最后，这显然不是您想要的，因为其目的是更新多个用户，而不是只更新一个用户。
PUThttp://example.com/api/users +body
的行为类似于使用键放置地图
http://example.com/api/users
和主体的值。如果不存在新条目，则创建新条目，否则将覆盖现有条目

问题：
http://example.com/api/users

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

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

为保持一致性，正文应包含一个用户数组：

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

在put请求的URL中包含id的另一个好处是创建/更新函数可以共享一些逻辑

假设这个用户表有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主体没有太大关系，但实际上它可以简化请求处理的代码，具体取决于您的语言/框架。
这很有意义。我的假设是，id将始终与资源一起提供，但我猜情况并非总是如此。事实上，如果您开始在接口中使用URI，您可能很快就会发现从资源表示本身删除id很有用。RFC-2616被@prasanthv淘汰了。您的意思是，PUT有什么变化吗？我不这么认为。我怀疑这是可能的，因为身体会有所不同。即使您正在更新同一资源，也可能会对其进行不同的更新（使用不同的值），忽略其中一些更新是一种非常意外的行为。无论调用了多少次，幂等动词都应该具有相同的效果。这是标准规定的。如果请求完全相同，则这可能是真的。假设我们有两个请求
PUT:/api/users/1
，它们的主体是
{“name”：“Foo”}
和
{“name”：“Bar”}
。幂等并不意味着第二个请求将被忽略，对吗？它只是意味着执行完全相同的请求将具有与只执行一次相同的效果。“作为幂等动词并不意味着第二个请求将被忽略”-是的，这是正确的。但它可能！它在网络中的中间节点上决定是否要使用相同的URI通过第二个PUT请求。HTTP标准允许在某些情况下（例如，流量拥塞）忽略具有相同URI的先前请求。我相信重要的是URI，而不是整个请求的正文。我认为这非常好。我认为这是一个API设计的好例子。这可能不是我在公共API中所允许的，因为一次更新这么多资源可能是危险的，但是感谢您提供的示例。