嘿，这个问题绝对是REST API设计里绕不开的经典困惑，我踩过不少坑，也看过很多成熟项目的最佳实践，今天就给你掰扯清楚：

首先得明确每个参数位置的核心用途，别乱塞：

Header：放「请求元数据」，和资源本身无关的内容 #

Header是用来描述请求的“属性”，不是资源数据本身，比如：

• 身份验证Token：标准做法是放在Authorization头里（比如Bearer {your-token}）
• 内容类型：Content-Type: application/json告诉服务器请求体是JSON格式
• 其他元信息：比如语言偏好Accept-Language、缓存控制Cache-Control、跨域相关的Origin等
• 核心原则：敏感信息（比如Token）优先放Header，避免暴露在URL/Query里

URL：放「资源标识符」，用来定位资源 #

REST是面向资源的，URL就是资源的“地址”，所以：

• 唯一标识资源的ID：比如用户ID、订单ID，必须放在URL路径里，比如/users/{userId}、/orders/{orderId}
• 资源的层级关系：比如/users/{userId}/orders，体现用户下的订单资源
• 核心原则：URL要简洁、语义化，一眼就能看出要操作哪个资源

Query参数：放「可选的筛选/控制参数」，用来调整返回结果 #

Query是对资源请求的“补充说明”，不影响资源的身份，比如：

• 过滤条件：/users?role=admin筛选管理员用户
• 分页参数：/users?page=2&size=10获取第二页数据
• 排序规则：/users?sort=createdAt,desc按创建时间倒序
• 搜索关键词：/users?search=john搜索名字含john的用户
• 核心原则：非必填、用来调整返回结果的参数，都丢Query里

Body：放「资源的核心数据」，尤其是创建/更新的内容 #

Body是用来传递资源本身的结构化数据，适合内容较多或需要格式化的场景：

• 创建资源时的字段：POST请求里的新用户信息{"name": "Alice", "email": "alice@example.com"}
• 更新资源时的字段：PUT/PATCH请求里的修改内容
• 核心原则：GET请求尽量别用Body（虽然HTTP规范允许，但很多客户端/服务器不支持，容易踩坑）

假设你的API是操作某个业务对象（比如Product、User），支持GET/PUT/POST/DELETE，参数位置这么放就对了：

GET请求（获取单个/列表对象） #

• Token：放在Header的Authorization头里
• 单个对象的ID：放在URL路径，比如/api/products/{productId}（定位具体产品）
• 列表请求的筛选/分页/排序：全部放在Query参数，比如/api/products?category=electronics&page=1&size=20
• 注意：绝对别用GET传Body，遵守行业约定，避免兼容性问题

POST请求（创建新对象） #

• Token：放在Header的Authorization头里
• 新对象的字段（除了ID，一般ID由服务端生成）：放在Body里，比如{"name": "无线耳机", "price": 999, "stock": 100}
• URL只需要资源集合路径：/api/products（不需要ID，因为对象还没创建）

PUT请求（更新整个对象） #

• Token：放在Header的Authorization头里
• 要更新的对象ID：放在URL路径，比如/api/products/{productId}（明确要更新哪个产品）
• 更新的完整字段：放在Body里，比如{"name": "新款无线耳机", "price": 899, "stock": 50}（PUT是幂等操作，建议传完整对象数据）

DELETE请求（删除对象） #

• Token：放在Header的Authorization头里
• 要删除的对象ID：放在URL路径，比如/api/products/{productId}
• 一般不需要Body，如果有特殊删除条件（比如需要验证用户密码），可以把验证信息放在Header或Query，尽量别用Body保持简洁

1. 敏感信息（Token、密码等）绝对不能放URL/Query，会被日志、浏览器历史记录下来，严重不安全
2. 幂等性：PUT/DELETE是幂等操作（重复请求结果一致），参数放URL/Header更符合特性；POST是非幂等的，用Body传创建数据更合理
3. 可读性：URL别塞太多参数，复杂的资源数据放Body，筛选控制放Query，让API一眼就能看懂

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