我参加了一个开发者大会，发言人认为以下一组网址不是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
答案 0 :(得分：1)
我同意，RESTful接口的整个想法（据我所知）是允许访问“资源”。所以这些URL方案对我来说都不是很好。
虽然说REST不是一成不变的，但它更多的是指导而不是一套规则。有些事情并不适合它，所以你必须尽可能地使用HTTP动词。
密码重置不是资源，但密码是。所以，我会在这些方面说些什么来进行密码重置操作...
GET /users/antonyscott/password
PUT /users/antonyscott/password
第二个呼叫需要从第一个呼叫派生的某种类型的身份验证并传入新密码。实际上，这比密码更改更直接。如果您在重置后（即 - 通过电子邮件中的链接确认重置），那么您所拥有的内容似乎没问题。
显然，设计一个API是一个迭代过程，所以我想说，看看它是如何工作的，然后进行优化。