.NET Core Web API复杂查询输入：HttpGet还是HttpPost更合适？

针对你这个检索用户的查询接口，我会从REST语义、实用性、性能三个维度分析两种方法的优劣，再给出最优选择：

一、优先考虑HttpGet的理由 #

虽然你提到参数是结构化JSON，但当前场景是扁平参数（name、pageSize、pageNo），完全可以适配HttpGet的使用场景：

• 符合REST语义：GET方法的核心就是获取资源，其他开发者看到接口名+GET方法，一眼就知道这是查询操作，无需额外理解成本。
• 天然支持缓存：浏览器、CDN、网关等中间件会自动缓存GET请求的响应结果，重复相同查询时直接返回缓存，能大幅降低服务器压力，提升响应速度。
• 可分享/书签化：查询参数会拼在URL里，用户可以把这个查询链接存为书签，或者分享给其他人，POST请求做不到这一点。

在.NET Core里实现也很简单，只需要定义查询模型并加上[FromQuery]特性：

public class UserQueryModel
{
    public string Name { get; set; }
    public int PageSize { get; set; }
    public int PageNo { get; set; }
}

[HttpGet("api/GetUsersByName")]
public IActionResult GetUsersByName([FromQuery] UserQueryModel query)
{
    // 执行查询逻辑
    return Ok(users);
}

客户端请求时直接用查询参数：http://localhost:4200/api/GetUsersByName?name=test&pageSize=10&pageNo=1，完全不需要传JSON请求体。

二、什么时候考虑用HttpPost？ #

只有当你的查询参数变得非常复杂（比如嵌套对象、多维度筛选条件、数组类型参数），导致URL长度超出限制（一般浏览器默认限制2048字符），或者参数编码后可读性极差时，才考虑用HttpPost。但它的缺点也很明显：

• 违背REST语义：POST方法的默认语义是创建资源，用它做查询会让接口的意图混淆，增加团队协作的理解成本。
• 无法缓存：POST请求默认不会被中间件缓存，每次查询都会直接打到服务器，性能不如GET。
• 不可分享：请求体里的参数不会出现在URL中，无法保存或分享查询状态。

如果一定要用POST做查询，建议修改端点命名来明确语义，比如改成/api/Users/Query，而不是带"Get"前缀的名称。

三、针对当前场景的最优选择 #

优先使用HttpGet。你的参数是简单的扁平结构，完全可以拆分为URL查询参数，既符合REST规范，又能享受缓存、可分享等优势。如果未来参数复杂度提升，再考虑切换到Post或者用自定义模型绑定来适配复杂参数的GET请求。

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