我們有一種設計，用戶可以訪問產品，但只能在某個類別中訪問。授權和REST API設計中的查詢字符串
超級用戶可以使用簡單的GET請求列出所有類別中的所有產品，例如GET /products。
通過查詢字符串已經存在簡單的過濾，所以超級用戶已經可以通過請求GET /products?category=N將他的搜索限制到類別N.
假設用戶X已通過身份驗證，並且用戶X可以訪問類別爲3的產品。
如果一個API服務器：
GET /products?filter=3，並且GET /products會失敗403 Forbidden？ - 或GET /products，並將結果靜默過濾爲用戶有權訪問的結果？這兩種解決方案都是完全有效的。當用戶沒有查看權限時，您總是可以隱藏這些內容。這意味着您可以顯示實際用戶的過濾表示/products，或者您可以隱藏/products資源，並只提供鏈接到/products?filter=3資源。我認爲這裏沒有最佳做法，因爲這兩種解決方案都很容易實施。
@VoiceOfUnreason：
顯然你沒看過Fielding的工作不夠仔細。
更改取決於資源在哪個用戶 看它給我的印象是一個壞主意（TM）的代表性。
該表示取決於整個請求，而不僅僅是在GET /resource部分。 Authorization標頭也是HTTP請求的一部分。因此，根據Authorization標題更改表示在REST中有效。這與根據Accept標題更改表示方式相同。或者你是否說我們應該提供XML，即使有人要求使用JSON？認爲單個資源只能有一個表示形式是一個巨大的錯誤。另一個錯誤返回一個損壞的鏈接給客戶，讓他們通過發送無意義的HTTP消息浪費資源......
考慮，例如，在一個URI被 兩個用戶之間共享的使用情況。他們每個都導航到「相同」的資源，但獲取兩個不同實體的表示。
REST是用於機器對機器的通信，而不是用於人機對話的通信！瀏覽器不是REST客戶端。或者你的意思是說Facebook的機器人將與谷歌爬蟲分享鏈接？這樣的廢話...
期望一個簡單的GET/products並將結果默認過濾爲那些用戶有權訪問的結果？
更改資源的表示形式取決於哪個用戶正在查看它罷工是一個壞主意[tm]。
例如，考慮uri在兩個用戶之間共享的用例。他們每個導航到「相同」的資源，但回來兩個不同entites的表示。
記住 - 這裏就是菲爾丁不得不說一下資源
的REST信息的關鍵抽象是一種資源。任何可以命名的信息都可以是資源：文檔或圖像，時間服務（例如「今日洛杉磯的天氣」），其他資源的集合，非虛擬對象（例如人）等等。換句話說，任何可能成爲作者超文本引用目標的概念都必須符合資源的定義。資源是對一組實體的概念映射，而不是與任何特定時間點的映射對應的實體。
現在，有這取決於用戶的角度映射的概念（例如「今天的我城市天氣」）。但通過將工作委派給另一個資源（臨時移動到「今天的Camelot中的天氣」），我比將自己的授權證書作爲資源標識符的隱藏部分處理更加舒適。
如果您的API的消費者在這個資源通過以下鏈接到達，然後在未經過濾的拼寫403 Forbidden是罰款。另一方面，如果消費者應該將這個URI加入書籤，那麼將其作爲重定向調度器來實現可能更有意義。
重定向的方法是通過調遣的有關內容協商對話的rest-discuss list in 2006
重定向一般來說發表的言論一致，我避免內容協商沒有的，因爲它在緩存效果像瘟疫 重定向。
例如，如果你點擊一個鏈接到
那麼網站將根據用戶的偏好之一