如何构造带复杂对象的WebApi合法GET请求？

首先得指出一个关键问题：你的接口定义本身就不符合HTTP规范和ASP.NET Core的设计逻辑——GET请求不应该使用[FromBody]特性。HTTP标准里GET请求是不带请求体的，虽然少数客户端能强行发送带请求体的GET，但ASP.NET Core默认会忽略GET请求的请求体，这会导致你的CustomObject[] obj参数永远拿不到值。

另外还要提个小细节：你的类名拼错了，CustomeObject应该改成CustomObject，不然模型绑定会失败。

下面给你几个可行的解决方案：

方案1：将复杂对象转为查询参数（适合小型数组） #

如果你的CustomObject数组元素不多，可以把对象的属性拆成带索引的查询参数，让ASP.NET Core的模型绑定自动解析。

修改后的接口： #

[HttpGet("{param1}/{param2}")]
public async Task<IActionResult> GetRequest(string param1, int param2, CustomObject[] obj)
{
    // 这里实现你的业务逻辑
    return Ok();
}

合法的GET请求示例： #

GET /api/YourController/param1Value/123?obj[0].Name=Alice&obj[0].Email=alice@test.com&obj[1].Name=Bob&obj[1].Email=bob@test.com

这里param1Value是你的param1参数值，123是param2的数值，后面的查询参数对应数组里的两个CustomObject实例。

方案2：改用POST请求（适合大型/复杂对象） #

如果你的CustomObject数组很大或者结构复杂，GET的查询参数长度会受限（不同服务器限制不同，一般是几KB），这时候更适合用POST请求把复杂对象放在请求体里。

修改后的接口： #

[HttpPost("{param1}/{param2}")]
public async Task<IActionResult> GetRequest(string param1, int param2, [FromBody] CustomObject[] obj)
{
    // 实现业务逻辑
    return Ok();
}

合法的POST请求示例： #

• 请求URL：POST /api/YourController/param1Value/123
• 请求头：添加Content-Type: application/json
• 请求体（JSON格式）：

[
    {
        "Name": "Alice",
        "Email": "alice@test.com"
    },
    {
        "Name": "Bob",
        "Email": "bob@test.com"
    }
]

方案3：将对象序列化为字符串放在查询参数（不推荐，仅万不得已时用） #

如果一定要坚持用GET，可以把CustomObject[]序列化为JSON字符串，URL编码后作为单个查询参数传递，接口内部再反序列化。

修改后的接口： #

using System.Text.Json;

[HttpGet("{param1}/{param2}")]
public async Task<IActionResult> GetRequest(string param1, int param2, string objJson)
{
    var obj = JsonSerializer.Deserialize<CustomObject[]>(objJson);
    // 实现业务逻辑
    return Ok();
}

合法的GET请求示例： #

先把数组序列化为JSON字符串：

[{"Name":"Alice","Email":"alice@test.com"},{"Name":"Bob","Email":"bob@test.com"}]

然后对这个字符串进行URL编码，得到：
%5B%7B%22Name%22%3A%22Alice%22%2C%22Email%22%3A%22alice%40test.com%22%7D%2C%7B%22Name%22%3A%22Bob%22%2C%22Email%22%3A%22bob%40test.com%22%7D%5D
最终请求URL：

GET /api/YourController/param1Value/123?objJson=%5B%7B%22Name%22%3A%22Alice%22%2C%22Email%22%3A%22alice%40test.com%22%7D%2C%7B%22Name%22%3A%22Bob%22%2C%22Email%22%3A%22bob%40test.com%22%7D%5D

这个方法的缺点是可读性差、有URL长度限制，除非必须用GET，否则优先选前两个方案。

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