休息：对错选择网址，Usecases

Question

我是一个开发者大会在扬声器认为，下面一组URL不是基于REST：

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

给出的主要理由是，相同的URL可能在不同的情况下使用，并且这不会以有意义的方式促进HATEOAS。 然后，他继续认为更可行的方法是使用以下URL：

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

根据该后一种方法允许每个用例具有用于每一个专门定制（HTML-）形式的扬声器网址，然后可以发布到相同的网址。在不同的上下文中使用相同的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是一个迭代过程，所以我会说，去看看它是如何工作的，然后再细化它。