休息：从用例中选择 URL 的正确或错误

Question

我参加了一个开发者大会，演讲者认为以下一组 URL 不是 RESTful：

/users/username/changepassword
/users/username/resetpassword

给出的主要原因是相同的 URL 可能在不同的上下文中使用，这并没有以有意义的方式促进 HATEOAS。 然后他继续争辩说，更可行的方法是使用以下 URL：

/account/changepassword
/administration/server/users/username/resetpassword

根据演讲者的说法，后一种方法允许每个用例为每个 URL 提供一个专门定制的 (html-) 表单，然后可以将其发布到同一个 URL。在不同的上下文中使用相同的 URL 不再有问题。

我会自发地说这些 URL 集都不是 RESTful 的，仅仅是因为它们都以动作（动词）为中心，在我看来这些动作（动词）并不能真正成为资源，除非在特殊情况下（如搜索） .我觉得这个设置很像 RPC。

我会建议一些更像名词和颗粒状的东西

 //Change password
 PUT /users/username/account/password
 //Register reset
 POST /users/username/account/password/resets
 //Verify reset
 PUT /users/username/account/password/resets/0/verification_code

你的意见是什么？演讲者是否采用 RESTful 方式，还是这里没有足够的信息？

Answer 1

我同意，RESTful 接口的整个想法（据我所知）是允许访问“资源”。所以这些 URL 方案对我来说都不是很好。

虽然 REST 并非一成不变，但它更像是一种指南，而不是一套规则。有些事情不适合它，所以你必须尽可能地使用 HTTP 动词。

密码重置不是资源，但密码是。所以，对于密码重置操作，我会说一些类似的话......

GET /users/antonyscott/password
PUT /users/antonyscott/password

第二次调用需要从第一次调用派生的某种身份验证并传入新密码。实际上，这更像是直接更改密码而不是重置。如果您在重置之后（即，点击电子邮件中的链接以确认重置），那么您所拥有的似乎还不错。

很明显，设计 API 是一个迭代过程，所以我想说试试看它是如何工作的，然后改进它。