如何處理REST API結構冗餘？

我目前正在爲Web服務構建一個REST API，其中包括處理用戶禁令。如何處理REST API結構冗餘？

目前的API，我設計的樣子：

網址：GET /user/<user_id>/bans/<session_id>

說明：獲取關於指定用戶指定的會話的禁令。

輸出：

{ 
    session_id: 1, 
    banned_until: "..." 
}

網址：GET /user/<user_id>/bans

說明：獲取指定用戶的所有禁令。

輸出：

[ 
    { 
    session_id: 1, 
    banned_until: "..." 
    }, 
    { 
    session_id: 2, 
    banned_until: "..." 
    } 
]

網址：PUT /user/<user_id>/bans/<session_id>

說明：設置或更新指定用戶指定的會話的禁令。

輸入：

{ 
    session_id: 1, 
    banned_until: "..." 
}

輸出：

{ 
    session_id: 1, 
    banned_until: "..." 
}

現在我的同事之一認爲，API是錯誤的，因爲，例如在PUT的情況下，用戶有指定session_id兩次：一次在URL中，一次在內容中，這兩個必須匹配（這意味着額外的檢查服務器端）。他對GET發表了同樣的評論，用戶在URL中指定會話ID以將其恢復到響應中，這意味着浪費帶寬。雖然我理解他的擔心，但我認爲目前的設計是這樣的，對於用戶來說更簡單（只關心一個數據結構），並且在服務器上進行額外的檢查並不需要做太多的工作相比之下它給用戶帶來的舒適感。

在REST最佳實踐中，有關於此的官方指南嗎？處理這個問題的常用/推薦方法是什麼？

來源

2015-09-18 ereOn

一般而言，我寧願在cookie中傳輸會話ID。 –

@BenjaminMaurer這些不是網絡會話，而是與發出請求的瀏覽器無關的遊戲會話。 – ereOn