0

我参加了一个开发者大会，演讲者认为以下一组 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，或者这里没有足够的信息？

4

1 回答 1

1

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

话虽如此，REST 并不是一成不变的，它更像是一种指南，而不是一套规则。有些事情不能很好地适应它，所以你必须尽可能地使用 HTTP 动词。

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

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

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

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

于 2012-09-11T19:26:21.177 回答