帶有管理視圖的 REST API 設計

Question

我有帶有端點的 API 應用程序：

/api/v1/accounts
/api/v1/accounts/id

API 具有角色授權（用戶、管理員）。 用戶可以將帳戶標記為可見或隱藏。 如果帳戶被隱藏，那么它在搜索（ /api/v1/accounts ）中不可見，但希望允許在“用戶模式”（隱藏隱藏）和“管理模式”（隱藏也可見）下搜索管理員。 即使標記為隱藏，用戶也可以看到他們的帳戶

實現它的最佳方法是什么？ 添加一個參數來檢測它是否是每個端點的管理員或創建單獨的端點？ （例如/api/v1/accounts和/admin/api/v1/accounts ）。 如果我使用調解器模式，應該為管理員（單一原則責任）進行單獨的查詢/命令還是保持一個？ 我正在從我的問題中尋找最佳解決方案

Answer 1

這是一個非常自以為是的問題，因此沒有答案是完整的或單一的事實。 我寫這篇文章是因為信息太多，無法放入評論部分，我想我可以為您提供一些很好的指導，以便為您做出最佳決定。

我也會表達我自己的意見，所以你也應該考慮到這一點。

話雖如此，首先我看到您正在使用.NET-Core和C# ，它們概述了您擁有的選項之一。 至少從ASP.NET MVC 3 開始，我們可以選擇使用區域，我認為這些區域可以使用 .NET 方式為您提供所需的行為。 你可以在這里閱讀 .NET Core 中的區域，這里有一個簡短的引用：

在以下情況下考慮在項目中使用區域：

• 該應用程序由多個可以邏輯分離的高級功能組件組成。
• 您希望對應用程序進行分區，以便可以獨立處理每個功能區域。

所以優點是：

• 您以/admin/accounts/...的形式獲得開箱即用的路由
• 將來如果您需要添加額外的管理功能，您可以輕松地將它們分開，這將使您的代碼更清晰，更易於維護

然而，我個人並不是這種方法的忠實粉絲。 首先，它對我來說似乎有點人為。 通常你最終會得到 95% 的重復代碼和一些小的調整，最后你需要維護的額外代碼是否值得你從這種額外的分離中獲得的好處是非常值得懷疑的。

也許區域畢竟是可行的選擇，但前提是您有相當多的功能可以封裝在其中，以便您獲得一些真正的好處。

結論：您可以，如果您決定求助於/admin/accounts/...解決方案，我建議您考慮區域使用情況，但我個人不會去那里。

第二種選擇您可能不會將項目復雜化太多，只需提供一些額外的路線來處理您的特定需求。 與此有關的問題有幾個，我將概述這些問題：

• 很多時候，例外變成了常態。 現在您需要為管理員提供一些額外的功能，一段時間后您將需要為管理人員提供一些功能。
• 你的資源標識符會變得非常不一致，即使它不是很專業，我認為在你的應用程序中有這樣的路由會有些難看。

事件雖然您沒有義務使您的服務成為 RESTful，但如果您遵循 REST 應用的一些約束，它會有所幫助。

首先，請求應該是無狀態的：

從客戶端到服務器的每個請求都必須包含理解請求所需的所有信息

換句話說，您在問題中描述的所有邏輯，請求應包含服務器返回正確響應所需的數據。 在更實際的術語中，我說的是JWT 之類的東西，您可以在其中聲明傳遞有關用戶的附加信息，以便服務器可以獲取正確的數據。

二、統一接口：

REST 由四個接口約束定義：資源識別； 通過表征操縱資源； 自我描述信息； 並且，超媒體作為應用程序狀態的引擎。

在您的情況下，我認為這是最重要的資源約束識別要獲得所需的資源，您實際上並不需要管理部分，它是您的應用程序業務邏輯的一部分，可以查看服務器提供的內容和所有信息需要獲取正確的數據應該在請求中而不是 URI。

結論：我認為您應該使用一些額外的數據擴展您的請求，以便讓服務器執行業務邏輯並保持路由現在的狀態。

然而正如你所見，像區域這樣的事情是存在的，而且微軟的人是比我和你更好的 API 設計師，所以這里沒有非黑即白的答案。

希望至少我設法讓你深思熟慮。