REST風格的API設計需要驗證

Question

我想開發與用戶認證相關的restful API。請建議我的網址設計是否正常。作爲背景信息，這些API使用LDAP目錄，例如microsoft AD。

1. 用戶登記 POST/AUTH /註冊 有效載荷：{用戶名： 「」，密碼： 「」}

2. 用戶登錄

POST/AUTH /登錄

有效載荷：{用戶名：「」，密碼：「」}

1. 密碼變化

PUT/AUTH/password_reset

有效載荷：{用戶名： 「」，OLD_PASSWORD： 「」，NEW_PASSWORD： 「」}

停用用戶 DELETE/AUTH/de_activate/{USER_NAME}

激活用戶

PUT/auth /中de_activate/{} USER_NAME

我也明白，我現在用的動詞在URL中。但是，由於這些API創建了一些資源[註冊API]並執行了一些操作[login api]，我繼續使用上面的URL。我將不勝感激任何投入。

問候 ·普拉薩德·卡蒂

Answer 1

這些變化我會做。我知道你已經知道URL路徑應該是名詞，動詞應該是GET，POST，DELETE等，以表明你想要查看，創建或刪除資源。

相反的：
POST /auth/register做POST /registrations

相反的：

POST auth/login做POST /logins或POST sessions

您的密碼重設路線是好的，但我不相信操作的資源相匹配。

相反的：

PUT auth/password_reset做POST /password_resets 是的，PUT行動都應該更新或替換的資源，但你有什麼其他資源，需要您提供新舊價值觀？上面的一個仍然準確，因爲你正在創建一個「密碼重置」，它引發了一個可能需要人們檢查他們的電子郵件並點擊一個鏈接的操作工作流程，但我認爲做PUT /passwords是有誤導的，因爲有效載荷是需要。

相反的：

DELETE /auth/de_activate/{username}做DELETE /users/{username}或DELETE /users/{userId}甚至與{"active": false}PUT /users/{username}。就我個人而言，我認爲硬刪除和軟刪除應該通過您的API透明。

，而不是和：

PUT /auth/de_activate/{username}做PUT /users/{username}與{"active": true}或POST /users/{username}/reactivations。

RESTful標準的目的是爲客戶製作一致且可預測的API。所有這些都是一套準則。這不是超級嚴格的或任何事情，所以最終它是由你的最佳判斷決定的。這些只是我所做的調整。