在这些RESTful用例中使用哪种HTTP方法?

创建应该使用post来完成,所以为用户创建一个新角色应该是post而不是put,我会说。这取决于您是否考虑将角色添加为角色的创建(在这种情况下,它是一个帖子)或用户的修改(然后是一个Put)。你对网址的表述方式向我推荐了前者,所以我会选择Post。

同样的参数也适用于角色的撤销。这是修改用户还是删除角色?如果前者,那么我会说“放”,如果后者,那么删除。

我自己的看法是,从一个静止的角度来看,删除通常是更好的选择。如果您处理事务日志,您将使用PUT——您不只是删除一些权限,而是添加一个事务,删除事务日志的权限,这也意味着每次执行该操作时都会获得一个表示该操作的唯一ID。

您提出的第一个解决方案是RESTful,因为您一直在使用HTTP谓词。第二个解决方案是不一致的,因为您正在使用Put删除某些内容。

如果要创建一个资源来表示注册和撤销事务,则可以执行以下操作:

POST /registrations

POST /revokations

现在,在revoke案例中,更明显的是您正在创建一个资源(revoke事务),它具有从用户中删除角色的副作用。缺点是现在您需要一个包含用户和受事务影响的角色的post主体。

我认为你的第一个解决方案绝对是最好的。

我建议第二个选项是删除。只要您唯一地定位一个资源,就应该尝试将操作视为对该资源执行的操作。因此,在您的情况下,您所使用的URL是角色的。因此,您可以从用户下删除该角色。这就是我看到它的方式,它使资源上的方法易于阅读。

而且,如果您确实放置了资源,通常会替换资源,这意味着您将整个资源发送到服务器。

一个旧问题,但不应像op.restful url中那样修改url 不能包含动词( register 和 revoke ) . 动词表示rpc或rest-rpc混合体系结构。

其他人很好地回答了动词选择问题,但我的2p/2c是:

• 具有用户角色的URL: http://someapp/user-roles
• 发布以创建新映射:
  • 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 http://someapp.com/user-roles/ {userId}/{roleId} -我的偏爱

post应该用于创建新资源,put用于更新现有资源