使用身份驗證作為上下文RESTful嗎？

Question

我想知道是否隱式使用當前經過身份驗證的用戶作為API交互的上下文是否為RESTful。 例如，假設我所有的API調用都使用標准HTTP安全性進行了身份驗證：

檢索用戶訂單列表的查詢是否應該明確？
否： http : //example.com/orders
是： http : //example.com/orders? userid= 1234

放置POST以創建新訂單時，JSON是否應包含用戶？
否：{orderref：'EXAM / 1'，項目：{...}}
是：{userid：1234，orderref：“ EXAM / 1”，項目：{...}}

無論哪種方式，我都將確保API僅允許當前用戶執行操作，但是我應該讓API調用者聲明每個操作的用戶ID嗎？

Answer 1

我想說的是，如果您可以訪問許多用戶的訂單並需要按用戶過濾它們，則僅應將用戶ID作為查詢傳遞。

如果用戶只能訪問自己的訂單，則不必傳遞用戶ID-基本查詢集應根據自己的身份驗證詳細信息對其進行限制。 可以說它可能不是RESTful的，但是不必擔心-大多數API可能不是100％RESTful的，您應該對您的應用程序做有意義的事情，而不用擔心它是否是RESTful的-它是指南，而不是鑄鐵需求。

Answer 2

在任何情況下，都取決於您使用哪種身份驗證類型（BASIC或令牌），您必須在對API發出請求的API調用（標頭）中發送用戶信息。

因此，當您說從Context使用經過身份驗證的用戶是否有效時，當然是

這里的示例代碼

api調用

headers.Authorization = 'Bearer ' + localStorage.getItem("tokenkey");

從請求中獲取用戶

RequestContext.Principal.Identity.Name

Answer 3

它是RESTful的嗎？ 我會說：是的。 沒有REST規范，所以沒有什么可以說不是。 HTTP確實允許這樣做，並且HTTP緩存實際上默認情況下應將對帶有Authorization標頭的GET請求的響應視為私有。

您應該使用這種設計嗎？ 我不知道！ 我認為使用每個用戶的端點是有好處的，因為將來它可能允許用戶A檢查用戶B的訂單。

實際上，在我們的API中，我們有一個與您的API類似的示例，但是我們兩者都有。

1. 我們有一個/users/1234端點。
2. 我們也有一個/current-user端點。

最初， /current-user端點只是重定向到實際當前用戶的uri，但最終我們決定實際上只是返回不重定向的完整對象（由於瀏覽器的重定向行為不佳）。

current-user端點確實有一個指向實際用戶資源的self鏈接。

總結一下。 我認為您很清楚，但是我認為創建具有一致表示形式的資源（無論是誰看）都具有強大的設計優勢。 它使事情變得更簡單更好。

並且也不要忘記，如果您實際上正在遵循REST，那么沒有理由沒有理由。 客戶只需要關心的是在某處有一個指向訂單列表的鏈接，而不管它的URL是什么。

Answer 4

+1為Matthew Daly的答案。 尤其是當經過身份驗證的用戶只能訪問自己的訂單時（我認為是這樣）。

如果您的經過身份驗證的用戶可以訪問的訂單列表不僅限於他自己的列表，我將這樣做：

/orders: the authenticated user's orders.
/orders/123: the specific user's orders.

如果123等於通過身份驗證的用戶的ID，那又如何？ 對於您的客戶而言，最有可能的情況是沒有問題。

通過設計REST服務，您會想到開發人員在使用您的API時可能會感到的舒適。 我會說，這是一個舒適的解決方案。

Answer 5

檢索用戶訂單列表的查詢是否應該明確？
否： http : //example.com/orders
是： http : //example.com/orders? userid= 1234

放置POST以創建新訂單時，JSON是否應包含用戶？
否：{orderref：'EXAM / 1'，項目：{...}}
是：{userid：1234，orderref：“ EXAM / 1”，項目：{...}}

如果用戶僅查詢自己的訂單，則不應在查詢中明確傳遞用戶ID-您應在HTTP標頭中傳遞用戶令牌，並且代碼應按提供的令牌提取用戶ID，並確定授權用戶是否有權查看或修改特定用戶數據。

如果要讓一個用戶獲取或修改另一個用戶數據，則可以設置其他終結點-類似於users/{userId}/orders或users/{userId}/orders/{orderId} 。 您仍將通過HTTP標頭傳遞用戶令牌，並且您的實現應檢查用戶是否對此操作具有管理員權限。