ASP.NET Web API与ASP.NET Core的URL匹配及路由规则差异咨询

已知Web API路由规则在ASP.NET Core的适配校验 #

针对你提到的3条在ASP.NET Web API中生效的规则，在ASP.NET Core中的适配情况如下：

• 规则1（通过Action名称推导HTTP请求方法）：默认不生效。ASP.NET Core Web API从3.0版本开始，默认要求所有Action必须显式标注HTTP方法特性（如[HttpGet]、[HttpPost]），不会自动从Action名称的Get/Post等前缀推导匹配的HTTP方法，除非手动配置自定义应用约定还原该行为。
• 规则2（无显式方法、无名称推导时默认匹配POST）：完全不适用。由于Core默认关闭了HTTP方法的自动推导逻辑，没有显式标注HTTP方法特性的Action不会被纳入路由映射表，根本不会参与请求匹配，自然不存在默认用POST兜底的逻辑。
• 规则3（参数维度参与路由匹配）：会触发歧义异常。也就是你遇到的同控制器下两个Get方法（一个无参、一个带int id参数），在Web API中可正常区分匹配，但在Core中抛出AmbiguousActionException的问题。

框架匹配算法的核心改动 #

两个框架的路由匹配体系从设计思路上就有本质差异，核心改动集中在3个维度：

1. 参数绑定的默认行为反转，直接改变路由匹配的候选范围
   ASP.NET Web API的默认模型绑定规则是：简单类型参数默认从路由值中取值，复杂类型参数默认从请求体中取值。也就是说带int id参数的Action，只有当请求路径中存在对应id的路由值时，才会被纳入匹配候选——如果请求路径没有id段，这个带参数的Action直接不会参与匹配，自然不会和无参的Get方法形成冲突。你示例中的两个Get方法，就是靠这套规则在Web API中被自动区分的。
   ASP.NET Core完全反转了这个默认规则：简单类型参数默认从查询字符串、表单值中取值，不会默认绑定路由值。这就导致带int id参数的Action，就算请求路径中没有id段，只要可以从查询字符串中获取id值，就会被判定为可以匹配当前请求，和无参的Get方法形成完全重叠的匹配范围，最终触发歧义异常。
2. 歧义判定的触发时机大幅提前
   ASP.NET Web API的匹配流程是先完成路由模板匹配、再做HTTP方法校验、最后做参数适配筛选，只有当两个Action最终完全无法通过请求特征区分的时候，才会抛出歧义异常。上述两个Get方法在Web API中，就是在参数适配阶段被自动区分，不会触发歧义判定。
   ASP.NET Core基于Endpoint的路由体系，在应用启动构建路由表的时候，就会提前扫描所有Endpoint的匹配规则：只要两个Endpoint的可匹配路径范围存在重叠，就会直接判定为歧义并抛出异常，根本不会走到运行时的参数适配环节。
3. 移除了隐式的HTTP方法推导约定
   ASP.NET Web API内置了隐式路由约定：Action名称只要以Get/Post/Put/Delete开头，框架就会自动给这个Action匹配对应的HTTP方法，不需要显式标注特性。
   ASP.NET Core为了减少隐式约定带来的不可预期行为，直接移除了这套内置推导逻辑。所有可响应HTTP请求的Action，必须显式标注HTTP方法特性才能进入路由表，无标注的Action只会被当作普通类方法，不会参与请求匹配。

对应框架的路由配置参考：

• ASP.NET Web API 路由配置
  
• ASP.NET Core Web API路由配置
  

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