REST API设计与管理员视图

Question

我有一个API应用程序，具有以下端点：

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

API具有用户和管理员角色的授权。用户可以将帐户标记为可见或隐藏。如果帐户被隐藏，则在搜索中不可见（/api/v1/accounts）。但是，管理员在“用户模式”（其中隐藏的内容仍然隐藏）和“管理员模式”（其中隐藏的内容也可见）下允许搜索。即使标记为隐藏，用户也可以查看其帐户。

如何最好地实现它？为每个端点添加检测是否为管理员的参数，还是创建分离的端点？（例如/api/v1/accounts和/admin/api/v1/accounts）。如果我使用中介者模式，应该为管理员创建单独的查询/命令（单一责任原则），还是保持一个？我正在寻找解决方案。

- J. Doe

---

我会选择管理端点... - cortisol

@Leron_says_get_back_Monica 一周过去了，但是没有得到答案，所以我删除了那个帖子并在这里发布了。 - J. Doe

Answer 1

这是一个非常主观的问题，因此没有一个完整或单一的真实答案。我写这篇文章是因为信息太多而无法适应评论部分，并且我认为我可以为您提供一些良好的指导，以便为您做出最佳决策。

我还会表达自己的意见，所以您也应该记住这一点。

话虽如此，首先我看到您正在使用.NET Core和C#，这在某种程度上勾勒出了您拥有的选项之一。自至少ASP.NET MVC 3以来，我们就可以使用区域（areas），我认为这将以.NET方式给您想要的行为。您可以在这里阅读有关.NET Core中的区域的信息here，以下是一个简短的引用：

考虑在项目中使用区域时： - 应用程序由多个高级功能组件组成，可以进行逻辑分离。 - 您希望对应用程序进行分区，以便可以独立地处理每个功能区域。

所以优点是：

• 您可以通过/admin/accounts/...获得盒外路由。
• 将来，如果您需要添加其他管理员功能，则可以轻松保持它们分开，这将使您的代码更清洁，更易于维护。

然而，我个人不太喜欢这种方法。首先，对我来说，这似乎有点不自然。通常情况下，您最终会得到95％的重复代码和一些小的调整，最后很值得怀疑是否值得维护额外的代码相比从这种额外的分离中获得的好处。

也许区域是可行的选择，但前提是您可以在其中封装相当多的功能，以便从中获得一些真正的好处。

结论：您有能力并且如果决定采用/admin/accounts/...方案，建议您考虑使用区域，但我个人不会这样做。

第二个选项 您可能不想让项目变得太复杂，只需提供一些额外的路由以处理您的特定需求。但这样做的问题有几个，我将概述如下：

很多时候，例外情况变成了常态。现在管理员需要一些额外的功能，过一段时间，管理者也会需要一些功能。您的资源标识符将变得非常不一致，尽管这不太专业，但我认为在应用程序中使用这样的路由会有点丑陋。

即使您没有义务使您的服务符合RESTful，但如果您遵循REST应用的某些约束条件，则会有所帮助。

首先，请求应该是无状态的：

每个客户端到服务器的请求都必须包含理解请求所需的所有信息。

换句话说，您在问题描述中所描述的所有逻辑，请求应该包含服务器返回正确响应所需的数据。更具体地说，我指的是像JWT这样的东西，您可以使用Claims来传递有关用户的其他信息，以便服务器可以获取正确的数据。

其次，统一接口：

REST由四个接口约束定义：资源标识符的识别；通过表示形式操作资源；自描述消息；超媒体作为应用程序状态的引擎。

在您的情况下，我认为这是最重要的约束条件资源标识。为了获取所需的资源，您实际上并不需要管理员部分，它是您的应用程序业务逻辑的一部分，谁能看到什么以及服务器需要获取正确数据所需的所有信息都应该在请求中而不是URI中。 结论：我认为您应该通过添加一些附加数据来扩展请求，以便让服务器执行业务逻辑，并保持现有路由方式。 然而，正如您所看到的，像区域这样的东西存在，Microsoft的人们比我和您更擅长API设计，因此这里没有黑白之分的答案。

希望至少我能给您一些思考的食粮。

- Leron