使用PUT动词同时实现资源创建与更新是否合规？风险及RFC查询

方案推荐 #

优先选择POST /jobs 创建资源、PUT /jobs/{jobid} 仅更新已有记录的方案，这更贴合REST架构的语义规范，能避免不必要的兼容性与逻辑混乱。

PUT混合创建与更新的其他后果 #

• 客户端兼容性问题：部分遵循严格REST规范的客户端会认为，PUT到不存在的jobid应返回404而非创建资源，这种预期差异会导致对接时的错误处理逻辑冲突。
• 资源标识管控风险：PUT创建要求客户端指定jobid，服务端需额外处理ID重复、格式不符合规则等情况，可能破坏服务端自身的ID生成策略（如自增序列、UUID生成逻辑），增加校验与冲突处理成本。
• 幂等性的隐性失效：虽然PUT要求幂等，但如果创建逻辑包含依赖外部状态的操作（如关联资源的计数更新），重复调用PUT创建可能导致非预期的副作用，违背幂等性原则。
• 调试与维护复杂度：同一个端点同时承载创建和更新逻辑，排查问题时需额外区分场景，日志分析、代码维护的成本都会提升。

相关RFC参考文档 #

• RFC 7231：定义了PUT方法的核心语义为"替换目标资源的状态"，若目标资源不存在，服务端可选择创建（但非强制要求）；POST方法则用于提交数据以触发处理，通常用于创建由服务端分配URI的资源（见4.3.4节PUT定义、4.3.3节POST定义）。
• RFC 9110（RFC 7231的更新版）：进一步明确PUT的幂等性要求，同时强调POST适合创建由服务端生成标识的资源，而PUT创建时客户端必须知晓目标资源的完整URI。

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