REST API 設計：一個帶有 if/else 邏輯的端點或兩個獨立的基於角色的端點

Question

我有一個 API 設計/版本控制難題。 假設我有一個端點/api/customers獲取所有客戶（忽略分頁）。 但是有一個轉折點：如果一個普通user訪問這個端點，他們只會得到該用戶創建的客戶，而不是其他人（我可以檢查訪問令牌和子字段以確定誰發送了請求）。 其他用例：如果admin訪問此端點，他們應該獲得所有客戶，無論是誰獲得了他們。

現在我的問題是從 API 設計的角度來看：在if/else controller 本身確定我是否返回 ALL（用戶）或特定客戶的端點（或 Iadmin）用戶和管理員？ 即所有客戶的管理員唯一端點將是/api/admin/customers並且普通用戶仍然可以訪問他們的/api/customers ？

Answer 1

在 REST 中，具有共享相同表示的多個資源是正常的。

例如，學術論文的“作者的首選版本”是其值隨時間變化的映射，而“在 X 會議論文集中發表的論文”的映射是 static。 這是兩個不同的資源，即使它們在某個時間點都具有相同的值。 區分是必要的，以便可以獨立識別和引用這兩種資源。 軟件工程中的一個類似示例是在引用“最新修訂版”、“修訂版號 1.2.7”或“Orange 版本中包含的修訂版”時單獨標識受版本控制的源代碼文件。 —— 菲爾丁，2000

與這種方法完全一致的是，您可能有一個資源用於“所有用戶”，而另一個資源用於“由 Bob 創建的用戶”。

事情變得曲折的地方是您想使用相同的資源標識符來提供不同的表示。 也就是說，當 Alice 查看“我創建的用戶”時，她會看到“Alice 創建的用戶”，而當 Bob 查看“我創建的用戶”時，他會看到“Bob 創建的用戶”。

一種可能性是讓“我創建的用戶”重定向到適當的資源。 當目標資源不在本地緩存中時，它適用於允許額外往返的“工作”值。

在 HTTP/2 中，服務器推送可能會讓您免去一些往返的痛苦。

共享緩存的規則應該保護您不會將 Alice 對“我”資源的視圖發送給 Bob，反之亦然，但了解各種標頭的含義很有用，這樣您就不會無意中禁用該保護。

在某些“讀取您自己的寫入”設置中，擁有不同的資源可能是一個問題，因為緩存不會知道不安全的請求已使兩種資源都無效。 Bob 通過 POST 向“我創建的用戶”創建一個新用戶，並且相應的緩存條目無效……但“所有用戶”是不同的緩存鍵，不會失效。 因此，如果 Bob 查看所有用戶視圖，他可能會看到以前緩存的副本，而沒有他剛剛在自己的視圖中看到的更改。

在某些情況下，考慮子資源是有意義的。

/api/customers
/api/customers#created-by-Alice
/api/customers#created-by-Bob

但是，如果您試圖減少正在交換的不相關數據的數量，那么這不是一個很好的選擇。

Answer 2

它應該是相同的端點。 否則，調用您的 API 的每個前端必須具有相同的邏輯來確定角色和端點映射。

Answer 3

這取決於您的項目。

1. 如果只有你提到的兩種情況
   • 僅獲取該用戶為regular用戶創建的客戶
   • 為admin用戶獲取所有客戶

然后，最好通過添加中間件來使用 1 個端點來檢查當前用戶角色。

2. 如果您打算擴展您的項目。 例如，如果還需要admin用戶來獲取該用戶創建的客戶，最好創建 2 個端點。 一個用於所有客戶，另一個用於當前用戶的客戶。 喜歡 - api/customers/all ， api/customers/me

Answer 4

我認為 /api/customers 對於提到的情況很好。 這類似於對索引的 web 頁面請求。html 將不同的內容返回給不同的用戶。

如果你想擴展它（例如 Alice 請求 Bob 的列表），你可以支持可選的查詢參數：

/api/customers?accessibleTo=bob
/api/customers?createdBy=bob

這可能需要授權檢查（Alice 是否有權訪問 Bob 的列表？），在未授權時返回 403（或 404，取決於您的理念）。

也不要忘記緩存。 避免不同用戶對同一個 URL (/api/customers) 的兩個請求會導致一個用戶獲取另一個用戶的列表的可能性。