一、用户资料修改：PUT和PATCH到底怎么选？

上个月我们团队就踩了这个坑——产品经理要求：??用户修改头像时不能影响其他信息??。如果直接用PUT /users/123，前端必须传回全部用户字段，否则没传的字段会被置空！最后我们用PATCH方法+JSON Patch格式才解决：

json复制
// 错误示范：PUT请求要求完整数据
{ "avatar": "new.jpg" } // 导致username等字段丢失

// 正确姿势：PATCH请求
[
  { "op": "replace", "path": "/avatar", "value": "new.jpg" }
]

??记住这个铁律??：全量更新用PUT，局部修改用PATCH，就像修房子时换整面墙和补一块砖的区别。

二、电商库存管理：POST竟比PUT更合适？

你以为创建商品库存用POST，修改库存用PUT？大错特错！真实场景是：??当用户下单时，必须用POST /orders触发库存扣减??。因为库存计算涉及促销规则、仓库分配等复杂逻辑，这根本不是简单的资源更新。

看个反面教材：

http复制
PUT /products/456/stock  // 错误！直接暴露库存操作接口
Content-Type: application/json
{ "quantity": -1 }

黑客分分钟刷空你的库存！正确做法是把减库存作为下单的副作用，通过领域事件驱动处理。

三、朋友圈动态删除：DELETE方法的安全陷阱

你以为DELETE /posts/789就能删动态？某社交APP去年就因为这个设计被黑产批量删帖。??现在我们的方案是??：

1. 前端用POST发送删除请求，携带二次验证token
2. 后端只标记is_deleted字段而非物理删除
3. 网关层限制DELETE方法每分钟最多10次调用

??血泪教训??：RESTful不是死规矩，重要操作必须加业务层防护。就像你家保险箱不能只用钥匙，还得有密码+指纹双重验证。

四、文件分片上传：POST的进阶玩法

做网盘系统时，5GB大文件上传必须分片处理。这时候纯RESTful规范就不够用了，我们的方案是：

http复制
POST /files/upload-sessions  // 创建上传会话
{
  "file_name": "movie.mp4",
  "total_size": 5368709120
}

PUT /files/upload-sessions/{sessionId}/parts/1  // 上传分片
Content-Range: bytes 0-1048575/5368709120

??核心思路??：用POST创建临时资源，用PUT上传分片。就像寄快递时先下单生成运单号，再分批送货上门。

五、灰度发布场景：OPTIONS方法的妙用

对接银行系统时发现个神操作——??用OPTIONS方法做接口探活??：

http复制
OPTIONS /transfer 
Access-Control-Allow-Methods: POST
X-Api-Version: v2

这样客户端不仅能检测接口可用性，还能知道当前使用的API版本。在灰度发布时，新老版本接口同时返回不同X-Api-Version值，配合网关实现流量分流。

[ 真实案例复盘 ] 某P2P平台因为GET /withdraw?amount=5000接口泄露，用户直接在浏览器地址栏重复执行提现操作。最终解决方案：??敏感操作全部改用POST+防重放机制??，请求头必须带一次性签名nonce参数。