休息：對錯選擇網址，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是一個迭代過程，所以我會說，去看看它是如何工作的，然後再細化它。