WebAPI路由配置异常：GetRecordsByIds带字符串参数调用失败求助

• 路由匹配顺序冲突：Web API路由按定义顺序从上到下匹配，只要路由结构匹配就会停止后续匹配。你定义的前两条路由结构完全一致，为api/{controller}/{action}/{参数}，Web API匹配时不识别参数名差异，请求GetRecordsByIds带字符串参数时会优先匹配第一条RecordObject路由，第一条路由对应的方法需要ObjectId类型参数，你传入的字符串无法转换为ObjectId，直接触发匹配失败。
• Action名称不匹配：你的GetRecordsByIds方法上加了[ActionName("GetRecordsById")]特性，相当于强制把该动作的名称改成了GetRecordsById，你请求路径里用GetRecordsByIds自然找不到对应动作。

方案1：调整集中式路由配置（保留现有路由规则） #

1. 先修正Action名称配置，要么删除[ActionName("GetRecordsById")]特性，要么将请求路径里的GetRecordsByIds改为GetRecordsById，保持两者一致。
2. 给第一条路由加参数约束，仅当第三个参数符合ObjectId格式时才匹配该路由，避免抢占普通字符串参数的请求：

config.Routes.MapHttpRoute(
    name: "RecordObject",
    routeTemplate: "api/{controller}/{action}/{objectId}",
    defaults: new { action = "List", objectId = RouteParameter.Optional },
    // 新增约束：仅匹配24位十六进制格式的MongoDB ObjectId
    constraints: new { objectId = @"^[0-9a-fA-F]{24}$" }
);

调整后，不符合ObjectId格式的字符串参数会自动走到第二条RecordString路由完成匹配。
3. 额外优化：你定义的第三条DefaultApi路由结构和常规Web API路由结构相反，容易引发不必要的匹配冲突，如果没有特殊业务需要建议评估后删除，或者调整到所有路由定义的最后面。

方案2：改用属性路由（更不易出现冲突） #

属性路由可以直接为每个接口指定路径，避免集中式路由的顺序冲突问题：

1. 先在WebApiConfig中开启属性路由支持，放在所有集中式路由定义之前：

config.MapHttpAttributeRoutes();

2. 放开你代码中注释的[Route]特性，可额外加参数类型约束增强准确性：

[HttpGet]
[Route("~/api/Records/list/{objectId:ObjectId}")]
public async Task<List<Records>> List(ObjectId objectId)
{}

[HttpGet]
[ActionName("GetRecordsById")]
[Route("~/api/Records/GetRecordsById/{ids}")]        
public async Task<JObject> GetRecordsByIds(string Ids)
{}

调整后直接请求https://localhost:44339/api/Records/GetRecordsById/LEECO-99HIS-00000-0MSFN即可正常调用。

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