POST作为非幂等HTTP请求方法的应用场景：为何选用POST而非幂等PUT？

POST的核心特性是非幂等——多次执行同一请求会产生不同的业务结果，典型应用场景包括：

• 客户端无法预定义资源URI的创建操作：比如提交订单、发布博客文章，这类场景下资源的唯一标识（如订单ID、文章ID）由服务器生成，客户端无法提前构造目标URI，重复提交会生成多个独立的资源。
• 触发状态变更的一次性操作：比如发起转账、发送验证码、触发退款，这类操作重复执行会导致重复转账、多次发送验证码等不符合预期的结果，HTTP层面依赖POST的非幂等语义来匹配这类动作（业务层可额外做幂等校验，但方法本身是非幂等的）。
• 表单提交类操作：比如用户提交注册信息、填写调研问卷，重复提交会产生多条重复的注册记录或问卷响应（除非业务层做去重，但HTTP方法的语义是非幂等的）。
• 依赖当前状态的批量操作：比如批量删除“状态为待处理”的任务，每次执行都会删除当前符合条件的任务，重复执行可能会删除后续新生成的待处理任务，每次结果都不同。

PUT的幂等性和通用性是有前提的：客户端必须知晓目标资源的URI，且PUT是对资源的全量替换。它的局限性正好对应POST的适用场景：

1. 客户端无法提前获取资源URI：很多创建场景中，资源的唯一标识由服务器生成（如订单ID、用户ID），客户端根本无法提前构造PUT所需的URI，这时候只能通过POST请求让服务器生成URI并返回。
2. 语义匹配度更高：PUT的语义是“将指定资源放置到目标URI，无论该URI是否已存在资源”，而POST的语义是“请求服务器执行一个动作，可能是创建资源、触发状态变化或处理数据”。比如触发支付动作，而非替换某个支付记录资源，用POST更符合语义，而非硬套PUT。
3. 支持部分更新或非资源替换操作：PUT要求全量替换资源，如果仅需更新资源的某个字段（如修改用户昵称），使用PUT需要传递整个用户对象，而POST可仅传递需要修改的字段（当然现在PATCH更适合部分更新，但不少老系统仍用POST处理这类场景）。
4. 非幂等操作的刚需：有些操作本身就需要非幂等特性，比如提交评论，重复提交应生成两条独立评论，而PUT重复执行只会替换同一条评论，无法满足这类需求。

当每次执行请求都应产生独立的新结果时，就不需要幂等性：

• 一次性资源创建：比如发布社交媒体动态、提交用户评论、创建新订单，重复提交应生成多个独立资源，而非覆盖或忽略。
• 触发一次性动作：比如发送验证码邮件、推送通知消息，重复请求应发送新的验证码或通知，而非返回之前的结果。
• 记录类操作：比如记录用户登录日志、操作日志，每次请求都应生成一条新的日志记录，重复执行会增加多条日志。
• 需要累加效果的操作：比如点赞功能中，如果业务逻辑是“每次点击增加一次点赞数”（而非切换点赞状态），重复请求需要累加计数，此时不需要幂等性（业务层可做防重复，但HTTP方法用POST符合语义）。

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