ASP.NET Core MVC项目客户端AJAX直接请求Web API是否为合理开发实践？

两种实现方式都是合规的开发实践，没有绝对的对错，具体选择要看你的项目实际需求：

直接前端AJAX调用Web API的适用场景 #

该方案适合以下场景：

• 目标Web API是团队内部开发的同域服务，或已经配置了规范的CORS跨域规则，不存在跨域调用问题
• 接口不需要使用服务端敏感密钥鉴权，前端仅需存储用户身份类凭证（如JWT）即可完成调用，不存在密钥泄露风险
• 不需要在请求层做额外的统一业务处理，比如评论敏感词过滤、用户请求频次限制、数据埋点统计、身份二次核验等操作
• 你的MVC项目仅作为前端渲染层，没有后端业务逻辑承载需求，该方案可以减少一次服务端转发开销，降低接口延迟，减轻MVC服务端压力

该方案的固有风险：

• 会直接暴露Web API的地址、请求参数结构，若API本身没有做完善的防刷、参数校验、权限控制，容易被恶意调用
• 后续API域名、请求规则调整时，需要全量修改前端代码，维护成本更高
• 无法处理需要服务端敏感信息参与的逻辑，如内部服务鉴权、加密参数生成等

走自有MVC服务端Action转发的适用场景 #

该方案适合以下场景：

• 需要在转发层做统一业务处理：比如评论内容前置审核、敏感词过滤、用户评论权限校验、统一添加API调用的内部鉴权密钥、统一错误处理、日志埋点等
• 目标Web API是内部服务，不对外暴露，或没有配置对外的跨域规则，不允许前端直接访问
• 项目后续有扩展需求，该方案下API调整仅需修改MVC服务端的转发逻辑，不需要动前端代码，维护成本更低
• 需要规避前端绕过校验直接调用API的风险，比如前端做了用户未登录不能评论的限制，服务端转发时可以二次校验用户登录状态，避免恶意调用

选型建议 #

• 若你的项目规模很小，Web API本身已经做了完善的安全校验，且没有额外的转发层需求，直接前端调用是完全合理的，不需要额外加转发层增加开发复杂度
• 如果项目有中长期扩展计划，或者有安全、统一业务处理的需求，优先选服务端转发方案，后期的灵活性和安全性更高

内容的提问来源于stack exchange，提问作者yevsh