目标是创建一个可以由本机移动设备（iOS，Android，Win Phone）以及具有各种表示层（asp.net核心MVC，Angular）的Web应用程序共享的api。
规划使用asp.net核心网络api来实现将由移动客户端以及javascript客户端使用的REST api。我的问题是，将在理想情况下将安全逻辑放在哪里使用其他表示层（如asp.net MVC）？如果我们在REST api中添加检查，那么asp.net MVC应用程序控制器将不得不使用HttpClient调用REST Web api，而不仅仅是引用业务层（共享类库）。
每个应用程序的身份验证将由json网络令牌处理，因为它们易于移动并且可以轻松扩展。因此，我的问题实际上是关于授权安全性及其存在的地方。
选项1：
Web API（安全性生活在这里）>业务/服务层>数据访问层>数据层
选项2：Web API>业务/服务层（安全性生活在这里）>数据访问层>数据层
在选项1中，这对于移动端和客户端前端来说是很好的，因为它们必须调用REST API，但是asp.net核心MVC必须使用HttpClient来调用REST API，而不是调用组成该API的共享类库。 buinsess /服务层。
在选项2中，所有REST api所负责的是调用在其中处理安全性的业务/服务层。
听起来您的目标是构建公共API。这应该是独立的，并且可以单独处理安全性-MVC网站只是另一个客户端（可能恰好生活在同一解决方案中），但理想情况下，它们之间不应有太多引用（基本上只是API合同）。这样，您还可以更早地捕捉到向后的向下兼容性问题，而不是MVC站点始终以强类型（即使通过重构）工作，而其他（尤其是移动客户端）则不会-您将拥有求助于对API进行版本控制。
如果您在服务器端采取某些措施（例如，缓存），则性能确实不应该成为问题，因为大量API都以这种方式工作。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句