具备保存、提交双操作的同一资源最优REST端点设计咨询

你目前初步拟定的两个核心端点本身是符合REST语义的：

• POST /foo：创建处于「草稿可编辑」状态的foo实例，为实例分配唯一资源ID，对应你提到的预保存操作
• PUT /foo/:id：修改指定ID的foo实例内容，仅当实例处于草稿状态时允许更新，一旦状态进入锁定阶段就直接拒绝写请求

在此基础上，针对你提到的两个核心疑问，可以按照以下思路设计配套端点：

已提前保存的草稿的提交操作设计 #

提交的本质是foo资源从「草稿可编辑」到「已提交不可修改」的状态流转，有两种业界通用的合规实现方式：

• 复用现有更新接口实现状态变更
  把「已提交」作为foo资源的一个常规属性，客户端发起提交时，通过PUT /foo/:id在请求体中把status字段设置为submitted即可。服务端在更新逻辑里内置校验规则：识别到状态变更为提交时，先校验所有必填项是否符合要求，校验通过后将资源标记为锁定状态，后续所有针对该ID的写请求直接返回409 Conflict，提示已提交资源不允许修改。
• 独立设计子资源端点隔离业务逻辑
  如果提交操作涉及的校验规则比较复杂，不想和普通草稿修改的逻辑混在同一个接口里，可以把提交动作抽象为foo的子资源，设计端点为POST /foo/:id/submissions。这个端点的语义是为指定草稿发起提交请求、触发状态流转，请求体不需要传完整的foo内容，只需要携带提交所需的校验参数即可。这种方式能把草稿编辑和提交的逻辑物理隔离，降低代码耦合度。

无预保存直接提交的端点设计 #

这种场景的核心需求是绕过草稿阶段，一次性提交所有内容直接生成锁定状态的foo实例，同样有两种可落地的设计方向：

• 新增独立的提交创建端点
  设计POST /foo/submissions作为独立入口，语义是直接创建已提交状态的foo资源。这个接口和POST /foo的逻辑完全隔离：请求体需要携带生成终态foo所需的全部字段，服务端直接执行提交校验规则，通过后生成带唯一ID的、不可修改的foo实例。
• 复用原有创建接口，通过参数标记初始状态
  不需要新增独立端点，在POST /foo的请求里增加initial_status参数，客户端如果需要直接提交就传initial_status=submitted，服务端根据参数判断是生成草稿还是直接生成已提交的终态资源。这种方式的优势是减少冗余端点，但一定要做好参数合法性校验，避免客户端随意传值绕过提交规则。

设计落地注意事项 #

• 所有状态锁定的判断必须在服务端做硬校验：无论通过哪个接口触发提交流程，只要foo进入已提交状态，所有写操作都要被拦截，不能仅依赖前端做按钮禁用。
• 长期未提交的草稿建议设置自动过期清理策略，避免无效数据占用存储资源。
• 不要设计成POST /submitFoo这类脱离资源路径的RPC风格端点，这类设计会破坏REST的资源语义，后续做权限控制、链路追踪都会增加额外成本。

内容的提问来源于stack exchange，提问作者Rui Araújo