JSON API 标准答案

【问题标题】：JSON API StandardJSON API 标准
【发布时间】：2021-12-01 18:44:29
【问题描述】：

我怀疑在使用 json api 标准和后端和前端之间的通信时有什么更好的选择。我只需要作者关联中的一个属性-“用户名”和其他内容应该为获取此内容的用户隐藏

案例a)

data: [
  {
    id: „100”, 
    type: „resource1”,
    attributes: {…},
    relationships: {author: {data: {id: „10”, type: „author”}}}
  }
],
included: [
  {
    id: „10”, 
    type: „author”,
    attributes: {username: „name”},
    relationships: {resources1: {data: [{id: „100”, type: „resource1”}]}}
  }
]

案例 b)

data: [
  {
    id: „100”, 
    type: „resource1”,
    attributes: {authorName: „name”, …},
    relationships: {author: {data: {id: „10”, type: „author”}}}
  }
],
included: []

案例 a) 看起来是语义化的，但在有效负载中提供了更多信息案例 b）更快地从作者那里得到我想要的东西（一个属性“用户名”，这是在附加属性中添加的：“作者名”），所以也不需要在前端进行关联。

有什么更好的做法，为什么？

【问题讨论】：

标签： json-api

【解决方案1】：

严格来说，case a 和 case b 根据JSON:API specification 都是有效的。

在情况下 username 是author 资源的一个属性。在 case b 中，authorName 是 resource1 的一个属性。 author 资源在 case b 中也可能具有 username 属性。在这种情况下，您有重复的状态。

如果您有充分的理由，我建议仅使用重复状态。重复状态增加了复杂性——无论是在服务器端还是在客户端。保持这两个属性同步会带来高昂的成本。例如。您需要更新在成功更新请求后resource1 更改的客户端，这会影响author 资源的username。并且客户端需要解析该响应并更新本地缓存。

有一些原因，其中复制状态有充分的理由得到回报。计算值是一个典型的例子，它需要客户端获取许多资源来计算它们。例如。您可能决定在product 资源上引入averageRating 属性，因为如果没有客户端，您只需获取产品的所有相关ratings 来计算它。

尝试减少有效负载大小几乎不是接受增加的复杂性的好理由。如果您考虑在网络级别压缩和打包大小，则原始有效负载大小通常不会产生太大影响。

【讨论】：