如何在RESTful Web服務中為“面向操作”的方法創建路徑？

Question

我正在創建RESTful Web服務，並且嘗試遵循慣例和推薦來創建良好的Web服務。 現在，我已經停下來了。 我的系統中有一個User實體，我有定期的CRUD路徑。 我想公開一個API以處理忘記的密碼。 它將在請求中使用用戶名，然后檢查是否找到用戶。 如果這樣做，它將更改密碼，並將密碼更改為自動生成的密碼，然后向用戶發送電子郵件。

我讀到以下內容： 與實體不對應的RESTful動作/服務？ 而且我看到也許應該開始將非數據庫實體也視為資源。

但是我在尋找API中忘記密碼的概念時仍然遇到問題。

我可以為路徑命名什么名稱，以及哪種HTTP方法合適？ 是否應該使用PUT，因為它將使用新密碼更新用戶？

Answer 1

我想公開一個API以處理忘記的密碼。 它將在請求中使用用戶名，然后檢查是否找到用戶。 如果這樣做，它將更改密碼，並將密碼更改為自動生成的密碼，然后向用戶發送電子郵件。

如果您真的想成為RESTful：

我可以為路徑命名什么名稱，以及哪種HTTP方法合適？

它不是PUT也不是GET ，因為它們是冪等方法（意味着您執行一次或10次應該得到完全相同的結果），而您想要的不是：如果請求10次，將生成10個不同的密碼。

還有其他原因，但以上內容很簡單，毫無疑問。 因此，一個POST是。

關於URL，因為password可以被認為是一個子資源 （的一部分） user ，考慮到該網址user資源http://www.example.com/rest/user ，是有意義的設計密碼的網址為：

http://www.example.com/rest/user/password

這樣，如果有人要設置密碼，他應該使用新密碼將PUT發送到該URL（冪等行為！）。

現在是密碼重置操作 ，我將其設為該URL的POST ，可能在POST正文中包含一些更具體的內容，例如password-reset和一些必要的關鍵字（可能是一個秘密問題的答案）。 如果該內容不存在，則400 Bad Request響應將是適當的。 如果請求者嘗試過多，則應在“重試等待期”期間發出403 Forbidden 。 不用說， PUT和POST都應在安全的，加密的（HTTPS，有人嗎？）通道內進行。

Answer 2

我認為您的方法有明顯的缺點。 認為您公開了為用戶生成新密碼的URL，例如： POST到URL http://mycompany.com/app/user/foobar/resetpassword

顯然，此URL不能使用密碼保護：否則，使用該密碼忘記了該密碼將無法重置它。 好的，這意味着知道用戶名的每個人都可以重置用戶密碼。 甚至每5秒一次。 或毫秒...好酷！

這意味着您必須以某種方式保護您的系統免受此類“天真的”黑客的攻擊。

我最近實施了類似的系統，可以為您提供建議的解決方案。

1. 公開允許啟動該過程的開放URL，例如http://mycompany.com/app/user/foobar/resetpassword 。 此URL不會更改密碼。 它只是創建包含另一個可點擊URL的電子郵件，例如http://mycompany.com/app/user/resetpassword/UNIQUETOKEN 。 令牌是您無法猜測的。
2. 用戶收到電子郵件，然后單擊鏈接。 這次更改了密碼，並將適當的電子郵件發送到了同一封電子郵件。

這種機制可保護您的系統免受天真的黑客的攻擊，並防止偶爾按下“重置密碼”按鈕，因為第一個操作實際上並未更改密碼。 只有可以訪問其電子郵件的用戶才能更改密碼。

關於令牌生成。 最好的解決方案是將令牌到密碼更改請求的映射存儲在數據庫中，這樣就可以限制單擊嘗試並使請求到期超時。 由於某些原因，我實現了更簡單的解決方案：令牌實際上包含加密的用戶名和請求密碼時的日期，因此我實現了請求到期，但不能限制對包含令牌的URL的點擊次數。 但是，實現非常簡單且無狀態。