在PUT请求的URI中包含Id

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资源与您打算使用的URI相同GET.

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 + bodyhttp://example.com/api/users其行为类似于将键和值放在主体中的地图。如果不存在则创建一个新条目，否则现有条目将被覆盖。

问：背后的资源是什么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'
  }
]