在这些RESTful用例中应该使用哪种HTTP方法？

Question

希望有人能帮我解决这个问题。

考虑以下使用情况：

1. 将角色添加到用户中

2. 从用户中删除/撤销角色

系统的接口是RESTFUL。

当添加角色时，使用以下URL：

PUT /user/{userId}/role/{roleId}

当从用户中删除/撤销角色时，使用以下URL：

DELETE /user/{userId}/role/{roleId}

我个人认为这两个RESTFUL调用都应该是PUT方法，并且URL也应该进行修改：

PUT /user/{userId}/register/role/{roleId}
PUT /user/{userId}/revoke/role/{roleId}

你有什么想法？

- JARC

Answer 1

使用POST来创建内容，因此为用户创建新角色应该使用POST而不是PUT。这取决于您是否认为添加角色是创建角色（在这种情况下是POST），还是修改用户（然后是PUT）。您所描述的URL方式让我认为是前者，因此我会选择POST。

相同的论点适用于撤销角色。这是对用户的修改，还是删除角色？如果是前者，那么我会选择PUT，如果是后者，则选择DELETE。

- skaffman

---

感谢您的回复。我认为这是对我的用户进行修改，因为角色已经存在。唯一需要创建的是关系...有趣。 - JARC

这就是为什么我对REST不太信服的原因。它看起来一切都很好，直到你尝试表达操作，然后它变得模糊不清。 - skaffman

使用PUT方法创建资源同样是有效的。唯一的条件是您需要事先知道roleId。 - Darrel Miller

Answer 2

你提出的第一个解决方案是符合RESTful规范的，因为你一直使用HTTP动词。而第二个解决方案不一致，因为你使用PUT来删除某些内容。

如果你要创建一个代表注册和撤销事务的资源，那么你可以这样做：

POST /registrations

POST /revokations

现在，在撤销案例中，更清楚地表明您正在创建一个资源（撤销交易），其副作用是从用户中删除角色。缺点是现在您需要一个包含受事务影响的用户和角色的POST主体。

在我看来，您的第一个解决方案绝对是最好的。

- Darrel Miller

Answer 3

一个老问题，但是URL不应该像OP那样被修改。RESTful URL不能包含动词（register和revoke）。动词表示RPC或REST-RPC混合体系结构。

其他人已经很好地回答了动词选择的问题，但我的意见是：-

• 用户角色的URL: http://someapp/user-roles
• POST请求创建新映射:
  • POST http://someapp.com/user-roles/{userId}/{roleId} - 我的首选
  • POST http://someapp.com/user-roles/{userId};{roleId}
    • 复合路径参数
    • 如何列出用户的角色？
  • POST http://someapp.com/user-roles?user={userId}&role={roleId}
    • 如何列出用户的角色？
• DELETE请求删除映射
  • DELETE http://someapp.com/user-roles/{userId}/{roleId} - 我的首选

POST 应该用于创建新资源，PUT 用于更新现有资源。

- David Kerr

Answer 4

我个人认为，从RESTful的角度来看，通常情况下DELETE更可取。如果您通过事务日志进行操作，则应使用PUT -- 您不仅要删除某些权限，还要添加一个事务以将该权限从事务日志中删除，这也意味着每次执行此操作时，您都会获得表示该操作的唯一ID。

- Daniel C. Sobral

---

感谢您的回复。资源“用户”和“角色”都有一个ID，但是它们之间的关系并没有导致唯一的资源ID，这就是为什么我认为使用PUT更合适的原因。 - JARC

Answer 5

我建议选择第二个选项使用DELETE。只要您可以唯一地定位资源，就应该尝试将操作视为在该资源上执行。因此，在您的情况下，您正在操作的URL是角色的URL。所以您应该从用户下面删除角色。这就是我看到的，并且这样做很容易阅读 - METHOD on RESOURCE。

而且，如果您使用PUT，通常会替换RESOURCE，这意味着您将整个资源发送到服务器。

- Charles Prakash Dasari