REST API多步骤操作的响应码选择及交易状态判定问题

嘿，这个问题问到点子上了！咱们结合REST的资源核心思想来拆解每个场景的响应码选择：

先明确基础前提 #

当你调用POST /transfer时，已经成功创建了一个处于pending状态的交易资源，所以这一步应该返回201 Created，同时在响应体里返回该交易的详情（包含id、status: pending），以及后续可用的操作端点（比如/transaction/123/commit、/transaction/123/verification/432）。毕竟资源已经存在，只是还没完成最终的转账动作。

各后续端点的响应码选择 #

1. POST /transaction/123/commit（确认完成转账） #

这一步是更新已存在的交易资源状态（从pending变为completed或success），而非创建新资源，所以：

• 操作成功：返回200 OK，同时在响应体里返回更新后的完整交易资源（包含最终状态、转账详情等）。
• 重复提交（交易已完成/取消）：返回409 Conflict，提示该交易状态不允许重复操作。
• 业务规则失败（比如余额不足、账户异常）：返回422 Unprocessable Entity，附带具体错误信息（比如“账户余额不足”）。
• 交易不存在：返回404 Not Found。

2. POST /transaction/123/verification/432（完成第二步验证） #

这类验证端点的核心是确认用户身份/权限，推进交易状态：

• 验证成功：返回200 OK，同时更新交易状态为verified，并在响应体里提示下一步操作（比如可以调用commit接口了）。
• 验证失败（验证码错误、身份不符）：返回422 Unprocessable Entity，或者更针对性的401 Unauthorized（如果是身份验证层面的失败）。
• 验证资源过期/不存在：返回404 Not Found。

3. 中止交易端点（比如POST /transaction/123/cancel） #

• 中止成功：返回200 OK，交易状态更新为cancelled。
• 交易已完成：返回409 Conflict，提示无法中止已完成的交易。

关键原则 #

REST API的响应码要贴合资源的生命周期变化：只有当你真正创建了新资源时才用201 Created，后续对已有资源的状态修改、操作确认，都用200 OK（或对应的错误码）就好。这样客户端能清晰识别资源的创建和状态变更动作，逻辑更清晰。

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