RESTful API可选查询参数处理规范：.NET接口的400错误问题咨询

核心规范边界说明 #

HTTP规范（RFC 3986）里，查询参数的键值对是key=value格式，value可以是空字符串（比如?from=），但undefined是JavaScript特有的概念，HTTP本身并没有定义这个值类型。REST风格的设计原则里，也没有强制要求必须处理这种非标准的参数值——规范层面的共识是：可选参数要么不传递，要么传递符合格式要求的有效值。

.NET API返回400的原因 #

你的.NET API返回400是框架默认的参数校验逻辑导致的：当你把from和to定义为日期类型时，模型绑定系统会尝试将传入的"undefined"字符串解析为日期，显然解析失败，因此返回Bad Request（400）。这是框架的严格校验行为，本身合理，但并非不可调整。

两种可行的处理方案 #

方案一：后端调整参数解析逻辑 #

如果要兼容前端传入"undefined"的场景，可以在后端手动处理这类值，将其视为null或直接忽略：

[HttpGet("endpoint/search")]
public IActionResult Search([FromQuery] string fromRaw, [FromQuery] string toRaw)
{
    // 将"undefined"字符串转为null
    var from = string.Equals(fromRaw, "undefined", StringComparison.OrdinalIgnoreCase) ? null : fromRaw;
    var to = string.Equals(toRaw, "undefined", StringComparison.OrdinalIgnoreCase) ? null : toRaw;

    // 后续处理日期解析与业务逻辑
    DateTime? fromDate = null;
    if (!string.IsNullOrEmpty(from))
    {
        if (!DateTime.TryParse(from, out var parsedFrom))
        {
            return BadRequest("from参数格式无效，请传入正确的日期");
        }
        fromDate = parsedFrom;
    }

    // 同理处理to参数...

    return Ok("查询成功");
}

也可以自定义模型绑定器或类型转换器，统一处理所有参数中的"undefined"值。

方案二：前端优化请求逻辑 #

从最佳实践角度，更推荐前端在请求时直接过滤掉值为undefined的参数，而不是传递key=undefined。比如用URLSearchParams时做判断：

const buildSearchUrl = (from, to) => {
  const params = new URLSearchParams();
  if (from !== undefined) {
    params.append('from', from);
  }
  if (to !== undefined) {
    params.append('to', to);
  }
  return `/endpoint/search${params.toString() ? `?${params.toString()}` : ''}`;
};

// 当from和to都是undefined时，生成的URL就是/endpoint/search

这种方式更符合HTTP参数的设计初衷，也能避免后端的校验报错。

OpenAPI规范的补充说明 #

OpenAPI里可以用nullable: true标记参数为可选且可为空，但同样没有规定要处理"undefined"这种非标准字符串。如果要兼容该场景，需要在OpenAPI文档中明确说明参数允许接受"undefined"值，并在后端实现对应解析逻辑。

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