依賴於上下文的REST API策略

Question

對於使RESTful API「依賴於上下文」，您建議採取什麼策略？

讓我詳細說明。

在我正在處理的項目上，我們正在公開資源Team。用戶可以創建自己的團隊，這會導致對API的POST /teams請求。該請求通過使用用戶創建團隊的一組規則進行驗證。

我們還有一個管理界面，某些用戶使用它來創建相同類型的資源，但是這由一組稍微不同的驗證規則來管理。

管理員可能會使用我們的公共或管理界面，因此驗證必須根據其上下文而不是用戶的能力進行。

要對上述問題進行重新說明以瞭解具體情況：我們如何以RESTful方式將這兩個上下文區分開來？即使「結果」是同一類型，我們是否也創建了兩個不同的資源？如果是的話，您會建議什麼樣的命名約定？

Answer 1

我相信你應該做的是爲每個管理員創建一個'用戶級'令牌或只是一個用戶，他們應該使用他們想要的公共接口。

根據REST API，只有一個接口，即/組，並且您的令牌可以決定驗證規則。

或者，如果每個管理員都是來自團隊的責任，我會設計/ admins/x/teams端點進行不同的驗證，並且只接受x的身份驗證。子資源仍然是RESTful。

Answer 2

REST中的任何內容都不能保證資源對於不同的客戶端的行爲相同。此外，由於授權信息附加到每個請求，因此資源分析它並將客戶特定的邏輯應用於請求是很自然的。

但是！如果資源上的某些操作引入了具有資源部分的相關生命週期的複雜資源不變量，那麼最好將其儘早重構爲較小的資源。例如，如果管理員應將member添加到team，然後普通用戶應在team中填寫member的詳細信息...您可能已經注意到，有兩個資源 - team和member。

提示：當分解一種參與不同的操作複雜的資源，你可以通過想象不同而造成的客戶未來的結垢問題得到新的想法。如果你會被這個資源的一個客戶所掩蓋，那麼你會如何爲另一個客戶獲得穩定的回覆呢？縮放不同資源比一個資源的不同部分更容易，因此請查看您的操作並考慮縮放。