寧靜的API設計：用戶和授權端點應該如何？

Question

基於類似的問題，我得出的結論是，針對GET請求設計此端點的最便捷方法應為：

GET /v3/users/
GET /v3/users/{userId}
GET /v3/users/{userId}/authorities
GET /v3/users/authorities/{authId}

我的問題是下一個端點應該如何：

1. Create authorities
POST /v3/users/authorities 
POST /v3/users/{userId}/authorities 

2. Update authorities
PUT/PATCH /v3/users/authorities/{authId} 
PUT/PATCH /v3/users/{userId}/authorities/{authId} 

3. Delete authorities
DELETE /v3/users/authorities/{authId} 
DELETE /v3/users/{userId}/authorities/{authId} 

你怎么看？ 直觀地講，我在所有情況下都采用第一個選項，但也許不是從主體傳遞userId的最好方法（我認為從URL傳遞userId更好）。 還是應該同時實現兩個端點？

Answer 1

第二種方法是更清潔，更標准。

PUT/PATCH/POST/DELETE.. /v3/users/authorities/{authId} - [1]
PUT/PATCH/POST/DELETE.. /v3/users/{userId}/authorities/{authId} -[2]

例如，在這里，如果您在uri中傳遞authId，為什么不使用userId呢？ 您將在此處遵循的標准是“ resource / {uniqueId} / attribute / {uniqueId}”。 理想情況下，在后端代碼中，您首先要查找特定資源，然后使用在uri中傳遞的鍵/ ID查找相同資源的特定屬性。 當動作將影響所有資源時，將省略id！

如果您使用方法[1]，則似乎您正在嘗試為所有用戶添加/更新/刪除權限！ 絕對不是這樣。

可以通過表單/帖子數據發送userId，但不是正確的方法。 在表單/帖子數據中，您應該發送將要添加/更新的值（在PUT / POST的情況下）。 類似於{authType：“ Admin”，isGlobal：true，有效自：“ 12/12/2015”}。 顯然，userId不適合此處。

Answer 2

首先，讓我說我同意Arghya的回答，但是我確實認為可能有理由將這些UPDATE和DELETE網址縮短到v3/authorities/{authId} 。

當然，這將假定authId對於該授權在整個應用程序中是唯一的。 我個人認為指定用戶沒有意義。 擊中該路線的人是否可以訪問該資源。

請記住，RESTful只是一種建築風格。 您應該做最適合您的技術堆棧的事情，並使您和與該API進行交互的客戶最有意義。