REST API中PATCH/PUT修改含生成属性资源的设计方案咨询

这类问题没有统一的强制标准，但行业内经过大量业务验证的通用实现思路是放弃非黑即白的「全可写/全只读」二元设计，从属性建模层面拆分字段类型，给不同类型的字段匹配明确的修改、同步规则，具体落地可以按以下步骤做：

第一步：拆分资源属性类型，从根源避免逻辑混淆 #

不要把所有服务端生成的字段归为同一类，按属性和分类规则的绑定强度拆成三类，每类的修改权限完全独立：

• 原生属性：由客户端直接提交的基础属性，比如商品名称、售价、关联的categoryId，这类字段和分类派生规则无关，PATCH/PUT操作时正常开放修改权限即可。
• 强绑定派生属性：取值100%由分类规则+原生属性计算得出、不存在合理人工调整场景的字段，比如「是否需要特殊仓储」「合规校验规则版本」这类完全由分类定义的属性，直接设为只读，任何场景下都不接受客户端传值修改。
• 可覆盖派生属性：服务端会在商品创建、分类变更时根据分类规则生成默认值，但业务上允许特殊场景人工调整的字段，比如你提到的过期时间、配送策略都属于这类。这类字段是解决灵活性问题的核心，必须配套存储元数据标记：比如过期时间字段为expireAt，就同步新增expireAtSource字段，枚举值为CALCULATED（按分类规则自动计算）/OVERRIDDEN（人工调整覆盖），从数据层面就不会出现「规则定义3天过期实际存20天」的逻辑混淆，所有偏离规则的取值都有明确标记，也方便后续审计、排查问题。

第二步：明确分类变更时的旧属性处理规则 #

针对修改商品关联分类时旧分类生成的高价值属性留存问题，同样按上述三类属性走差异化处理逻辑，不要一刀切全删或者全留：

• 强绑定派生属性：新分类存在对应字段规则的，直接按新规则重新计算值；新分类没有对应字段配置的，直接删除旧值——这类属性本身完全依附分类规则存在，没有独立留存的业务价值。
• 可覆盖派生属性：
  • 如果字段当前是OVERRIDDEN状态的人工调整值，默认保留，同时在接口响应中明确提示该字段为旧分类下的人工设置值，需要业务人员确认是否适配新分类；
  • 如果字段当前是CALCULATED状态的自动计算值，新分类有对应规则的按新规则重算，新分类无对应规则的删除旧值。
• 跨分类通用的高价值属性（比如你提到的用于配送调度的GPS坐标，如果不管商品归属什么分类都需要用到），本质不属于分类派生属性，应该直接归类到原生属性中，本身就开放给客户端维护，和分类规则解耦。

第三步：API层做明确的语义约束，避免黑盒操作 #

不要让客户端猜测字段的修改规则，接口设计上把约束做明确：

• 所有只读的强绑定派生字段，如果客户端在PATCH/PUT请求中传了修改值，直接返回400 Bad Request，明确告知对应字段为只读不可修改，不要静默丢弃参数，避免客户端误以为修改生效。
• 可覆盖派生字段正常开放修改权限，客户端传值修改后，后端自动将对应source字段标记为OVERRIDDEN；如果后续需要将字段恢复为按分类规则自动计算的状态，不需要重新关联分类，支持客户端传显式重置参数（比如传"expireAt": null, "resetExpireAt": true），后端收到后按当前分类规则重算值，将source改回CALCULATED即可。
• 分类变更操作不要和普通属性修改混为一谈：要么单独暴露/products/{productId}/change-category专用接口，要么在PATCH请求修改categoryId时，要求客户端显式传冲突处理策略参数conflictPolicy，可选值为keep_overridden/discard_all，后端按选定策略处理完旧属性后，要在响应中完整列出所有被重算、保留、删除的字段，不要做黑盒操作。

不要为了追求所谓的REST设计纯粹性强行做全只读约束，业务上的特殊调整需求是客观存在的，全只读的设计最终只会倒逼业务方绕开接口直接改库，反而会造成更严重的数据不一致。把字段的来源、修改规则做透明化标记，比假装规则永远没有例外要靠谱得多。

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