REST API（JSON API）中POST /quotes时客户端如何关联产品ID

首先咱们先锚定JSON API的核心设计原则：它更倾向于用relationships来表达资源间的关联，而非把关联信息塞进attributes里，这点先明确下来，方便咱们拆解各个方案的合理性。

先分析你提出的两个方案 #

方案1：先GET /products获取产品ID再传入 #

这是最贴合RESTful和JSON API规范的做法，优势很清晰：

• 完全遵循JSON API的资源关联模式，用产品的官方唯一标识（ID）建立关联，服务器端处理逻辑更统一，也符合资源引用的最佳实践
• 扩展性极强，后续产品属性变动时，客户端无需修改逻辑，只要拿到最新ID即可
• 无需维护额外编码规则，减少长期维护成本

缺点也很直接：多了一次网络请求，客户端需要先获取/搜索产品列表才能创建报价，增加了客户端的逻辑复杂度——如果产品列表庞大，还要额外做筛选、搜索的处理。

方案2：用固定不变的产品编码 #

这个方案的核心是用业务侧稳定的编码替代动态ID，分两个子方案看：

• 方案2a：把编码放在attributes里：不推荐这么做。JSON API里的attributes是用来描述当前资源（这里是quote）本身的属性，而产品关联是两个独立资源的关系，放在attributes里会混淆「属性」和「关系」的边界，不符合规范设计意图，也会让服务器端的关联逻辑变得混乱。
• 方案2b：把编码作为relationship的ID传入：这个是可行的，但有个前提——如果你的products资源的官方唯一ID就是这个固定编码（比如数据库产品表的主键就是acme_1这类编码），那完全符合JSON API的关系结构；但如果编码只是产品的一个业务属性（主键是自增ID），服务器端需要额外处理「通过编码查找产品ID」的逻辑，而且一旦后续业务要求编码变更（哪怕现在说永不变更，实际业务中很难绝对保证），所有客户端都要同步修改，风险较高。

这个方案的优势是减少了一次网络请求，客户端逻辑更简单，适合产品数量少、编码绝对稳定的场景（比如公司内部的固定产品线）。

其他可考虑的补充方案 #

1. 支持通过产品业务属性直接关联 #

如果不想让客户端先查产品，又想遵循JSON API的关系模式，可以让服务器端支持在relationships里通过产品的业务属性匹配资源，比如：

"data": {
  "type": "quotes",
  "attributes": {
    "foo": "bar"
  },
  "relationships": {
    "product": {
      "data": {
        "type": "products",
        "attributes": {
          "code": "acme_1"
        }
      }
    }
  }
}

服务器端收到请求后，根据product.attributes.code查找对应的产品，再建立关联。这种方式既保留了客户端的便捷性，又符合JSON API的关系设计。

2. 提供批量获取产品ID的接口 #

如果客户端需要频繁创建关联不同产品的报价，可以提供一个批量查询接口，比如GET /products?codes=acme_1,acme_2,acme_3，让客户端一次性拿到多个产品的ID，减少请求次数，同时依然遵循标准的ID关联模式。

总结建议 #

• 如果你的产品数量较多、编码存在变更风险，方案1是最稳妥的选择，符合规范且扩展性强
• 如果产品数量少、编码绝对稳定，优先选方案2b，但要确保编码是products资源的官方ID，或者服务器端能平滑处理编码到ID的转换
• 绝对避免方案2a，不要混淆属性和关系的边界

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