PUT与PATCH请求差异对比

PUT请求和PATCH请求均为HTTP协议中用于更新资源的方法，但在更新范围、数据传输要求及幂等性等方面存在显著差异，具体如下：

一、PUT请求

1.定义与作用

PUT用于整体替换或创建指定URI的资源。若资源已存在，PUT会用请求体中的完整数据覆盖原有资源；若资源不存在，可能会创建新资源并关联到该URI[^1][^5][^7]。

2.关键特性

• 幂等性：多次执行相同PUT请求的效果一致，不会产生额外副作用（如重复调用PUT更新用户信息，最终状态仅取决于最后一次请求数据）[^1][^5][^6][^7]。
• 数据传输范围：客户端需提供资源的完整实体表示，即使部分字段未变更也需包含，否则未提供的字段可能被清空[^1][^2][^5][^7]。

3.使用场景

适用于资源整体更新场景，例如：

• 替换用户的全部信息（姓名、年龄、邮箱等）[^1][^2]；
• 覆盖商品的完整属性（价格、库存、描述）[^5]。

示例

// PUT /users/123（更新用户123的全部信息）

{

"id": 123,

"name": "Alice",

"age": 25,

"email": "alice@example.com" // 需包含所有字段，否则未提供字段可能被清空

}

二、PATCH请求

1.定义与作用

PATCH是对PUT的补充，用于对现有资源进行部分更新，仅需传输需要修改的字段，无需提供完整资源数据[^1][^2][^5][^7]。

2.关键特性

• 幂等性：理想情况下应设计为幂等，但因仅修改局部字段，实现幂等性较复杂（如重复提交“增加库存10单位”的PATCH请求可能导致库存持续增加）[^5][^6]。
• 数据传输范围：客户端只需发送待修改的部分字段，未提及的字段保持原有状态[^1][^2][^4][^7]。

3.使用场景

适用于增量更新场景，例如：

• 修改用户的单个字段（如仅更新邮箱，无需提交姓名、年龄等未变更信息）[^1][^2]；
• 更新订单状态（如将“待支付”改为“已支付”，不影响其他订单信息）[^1][^5]。

示例

// PATCH /users/123（仅更新用户123的邮箱）

{

"email": "alice.new@example.com" // 仅包含需修改的字段

}

三、PUT与PATCH的核心区别

对比维度	PUT请求	PATCH请求
更新范围	整体替换资源（完整覆盖）[^1][^2][^5]	部分更新资源（仅修改指定字段）[^1][^2][^7]
幂等性	幂等（多次请求结果相同）[^1][^5][^7]	可能非幂等（需额外设计保证）[^5][^6]
请求体要求	需完整资源数据[^1][^2][^5]	仅需部分修改字段[^1][^2][^4][^7]
适用场景	全量更新（如用户信息完整替换）[^1][^5]	局部更新（如修改邮箱、订单状态）[^1][^2][^5]

四、注意事项

• PUT的“完整资源”要求：若客户端使用PUT时未提供完整字段，服务端可能将缺失字段置空或报错，需严格遵循“完整替换”语义[^2][^7][^8]。
• PATCH的幂等性设计：为确保PATCH幂等，建议通过“设置具体值”而非“增量操作”实现（如用{"age": 31}而非{"age": "+1"}）[^5][^6]。
• 非标准方法“UPDATE”：HTTP标准中无UPDATE方法，部分框架可能自定义该术语，但其行为需参考具体实现，不建议在RESTful API中使用[^5]。