我的RESTful API始終具有身份驗證功能，因此所有呼叫都會針對特定用戶進行身份驗證。用戶擁有的窗口小部件的URL的RESTful設計
這是一個更好的RESTful設計的URL通過HTTP協議？ 請記住，用戶標識3已通過基本http認證/摘要進行認證。
http://server.com/users/3/widgets/（返回所有小部件的用戶id 3）
http://server.com/users/3/widgets/13（返回微件ID 13）
或：
http://server.com/widgets/（返回用戶ID 3的所有部件）
http://server.com//widgets/13（返回微件ID 13）
是否總是有一個像http://server.com/users/3/widgets/這樣的獨特URL，甚至知道只有用戶＃3將是唯一一個訪問它？在每次通話時重新指定/用戶/ 3是多餘的，如http://server.com/users/3/widgets/
REST技術上應該是無狀態的，所以更「適當」的實現將是您列出的第一種方式。
但是，我會做的事情與第一種方法的建議略有不同 - 用戶會根據用戶的情況獲取有關特定窗口小部件更改的信息嗎？如果沒有，你可能想試試這個：
http://server.com/users/3/widgets/ (Returns all widgets for user id 3)
http://server.com/widgets/13 (Returns widget id 13)
獲得兩全其美。適當的「REST-ful」實現，但是當涉及到特定的小部件時，當前用戶無關緊要。通過這種方式，您的客戶可以更輕鬆地傳遞各個小部件的查詢 - 而無需自行更新查詢。如果客戶端無法訪問特定的窗口小部件，那麼使用您已經擁有的身份驗證來防止這種情況並不困難。
我也基於這一切，假設小部件列表可能因客戶端不同而不同 - 如果不是這樣，並且所有客戶端都會看到相同的小部件列表，無論如何，沒有理由通過用戶，所以用第二種方式。
我會第一次參加，因爲它完全指定了資源。
我肯定會推薦第一個選項。如果您選擇第二個，並且在某個時候您決定要允許緩存，那麼您必須確保您的變化標頭指定授權標頭上的表示方式不同。如果您使用過期的授權令牌，這可能會很痛苦。
這也意味着如果你想讓用戶看到其他用戶的小部件，你可以和緩存仍然工作。