首先是背景：我有一個應用程式，其中登錄用戶（員工）X 可以看到所有其他用戶（員工）的串列。如果登錄用戶 X 是管理員（他們的指定），那么他們還可以編輯他們管理的用戶的某些屬性。例如，正在編輯的用戶的位置、名稱和部門。需要注意的是，X 只能編輯那些向他/她報告的員工，這意味著有 X 不允許編輯的用戶。當 X 點擊用戶進行編輯時，他們導航到一個頁面，如http:myapp.com/dashboard/editUser/<ID_OF_THE_USER_BEING_EDITED>
顯然，X 可以聰明地手動編輯 URL 并輸入他們不允許編輯的用戶的 id，所以在加載編輯表單之前我需要檢查 X 是否有權編輯用戶 Y。如果 X 被授權這樣做，然后該頁面顯示一個表單（在適當的欄位中預先填寫用戶的當前屬性）以編輯用戶。否則，我會顯示“拒絕訪問”型別的訊息。
現在我已經創建了一個名稱非常糟糕的臨時端點 ( /api/v1/maybe_edit_user/?jwt=<TOKEN>&userId=<USER_BEING_EDITED>)。這個怪誕的端點做了兩件事：
- 它從令牌中提取當前登錄的用戶，并檢查它是否具有編輯用戶所需的訪問級別（通過 GET 引數傳遞
userId） - 如果是，則它在回應中回傳當前屬性（姓名、電子郵件、位置、名稱和其他內容），然后在顯示表單時在適當的欄位中預填充。
X 提交表單后，將向另一個端點 ( /api/v1/users/<USER_ID_OF_Y> PUT)發送 PUT 請求并更新用戶 Y。
雖然這有效，但我不覺得它有吸引力。我正在努力學習撰寫符合標準的更好、更清晰、更有條理的代碼。
REST 的最佳實踐建議所有端點都應該是名詞。另一方面，我的終點甚至不是一個簡單的動詞。這至少是一個被上帝遺棄的短語。
所以，這里的問題是：
- 我應該如何命名我的端點。
- 我是否應該使用單個端點來檢查權限，并獲取正在編輯的用戶的屬性，就像我現在正在做的那樣？或者我應該將它們分成 2 個獨立的端點？
uj5u.com熱心網友回復：
存在訪問控制串列這一事實是一個無關緊要的問題；忽略它。
資源識別符號標識資源。 資源是檔案的概括。
您需要一個與 RFC 3986 的生產規則一致的識別符號，并且選擇能夠利用 URI 模板 (RFC 6570) 的拼寫通常很方便（但不是必需的），否則機器并不關心。
這意味著你可以選擇一個讓人類更容易的拼寫；你可以在這里選擇優先考慮哪些人。
它在回應中回傳當前屬性（姓名、電子郵件、位置、名稱和其他內容）
這是你的提示，對檔案什么的; 鮑勃的……簡介的某種摘要？員工記錄？卷宗？這顯然是針對這種特定形式的使用而優化的。
所以識別符號可以很簡單
/this-specific-kind-of-form/source-data/Bob
一個請求可能看起來像
GET /this-specific-kind-of-form/source-data/Bob HTTP/1.1
Authorization: Bearer <token>
實作看起來很像您的草圖 - 驗證令牌，將宣告與所需的宣告進行比較，然后回傳資源或某種型別的客戶端錯誤 (4xx)。
REST 的最佳實踐建議所有端點都應該是名詞。
不要讀太多。
請注意，以下所有資源識別符號都有效：
- https://www.merriam-webster.com/dictionary/get
- https://www.merriam-webster.com/dictionary/post
- https://www.merriam-webster.com/dictionary/put
- https://www.merriam-webster.com/dictionary/patch
- https://www.merriam-webster.com/dictionary/delete
您可以單擊這些鏈接中的任何一個，您的瀏覽器將創建正確的 HTTP 請求，服務器將執行預期的操作。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/314021.html