我有带端点的 API 应用程序:
/api/v1/accounts
/api/v1/accounts/id
API 具有角色权限(用户、管理员)。用户可以将帐户标记为可见或隐藏。如果帐户被隐藏,则它在搜索中不可见 (/api/v1/accounts
) 但希望允许在“用户模式”(隐藏隐藏)和“管理员模式”(其中隐藏的也是可见的)。用户可以看到他们的帐户,即使它被标记为隐藏
实现它的最佳方法是什么?添加一个参数来检测它是否是每个端点的管理员或创建单独的端点? (例如 /api/v1/accounts
和 /admin/api/v1/accounts
)。如果我使用调解器模式,应该为管理员(单一原则责任)单独查询/命令还是保持在一个?我正在寻找问题的最佳解决方案
这是一个非常自以为是的问题,所以没有一个答案是完整的或单一的事实。我正在写这篇文章,因为评论部分的信息太多了,我想我可以为您提供一些好的指导方针,以便为您做出最佳决定。
我也会发表自己的看法,所以你也应该记住这一点。
话虽如此,首先我看到您正在使用 .NET-Core 和 C#,这概述了您拥有的选项之一。至少从 ASP.NET MVC 3 开始,我们可以选择使用 areas,我认为这会为您提供使用 .NET 方式所需的行为。您可以阅读 .NET Core 中的区域 here这是一个简短的引述:
Consider using Areas in a project when:
- The app is made of multiple high-level functional components that can be logically separated.
- You want to partition the app so that each functional area can be worked on independently.
所以优点是:
- 您以 /admin/accounts/...
的形式获得开箱即用的路由
- 将来如果您需要添加额外的管理功能,您可以轻松地将它们分开,这将使您的代码更干净,更易于维护
不过,我个人并不是这种方法的忠实拥护者。首先,这对我来说似乎有点做作。通常你最终会得到 95% 的重复代码和一些小的调整,最后你需要维护的额外代码是否值得你从这种额外的分离中获得的好处是非常值得怀疑的。
也许区域毕竟是可行的选择,但前提是您有相当多的功能可以封装在其中,以便您获得一些真正的好处。
结论:您可以,如果您决定求助于/admin/accounts/... 解决方案,我建议您考虑区域使用情况,但我个人认为不会去那里。
第二个选项
您可能不会使项目复杂化,而只是提供一些额外的路线来处理您的特定需求。这有几个问题,我将概述这些问题:
- 异常(exception)往往成为常态。现在您需要为管理员提供一些额外的功能,一段时间后您将需要为经理提供一些功能..
- 您的资源标识符将变得非常不一致,尽管它不是很专业,但我认为在您的应用中使用这样的路由会有些难看。
虽然您没有义务让您的服务成为 RESTful,但如果您遵循 REST 应用的一些约束,将会有所帮助。
首先,请求应该是无状态的:
Each request from client to server must contain all of the information
necessary to understand the request
换句话说,您在问题中描述的所有逻辑,请求应包含服务器返回正确响应所需的数据。用更实际的术语来说,我说的是像 JWT 这样的东西,您可以在其中通过 Claims 传递有关用户的附加信息,以便服务器可以为您获取正确的数据。
二、统一接口(interface):
REST is defined by four interface constraints: identification of
resources; manipulation of resources through representations;
self-descriptive messages; and, hypermedia as the engine of
application state.
在你的情况下,我认为这是最重要的约束资源识别要获得所需的资源,你实际上不需要管理部分,它是应用程序业务逻辑的一部分可以看到服务器获取正确数据所需的所有信息应该在请求中而不是 URI 中。
结论:我认为您应该使用一些额外的数据来扩展您的请求,以便让服务器执行业务逻辑并保持现在的路由。
但是
如您所见,区域之类的东西是存在的,并且 Microsoft 的人员是比我和您更好的 API 设计者,因此这里没有非黑即白的答案。
希望至少我能给你一些启发。