时间戳

首页 > 解决方案 > JSON API 标准

json-api - JSON API 标准

问题描述

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

案例一）

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

解决方案

严格来说，案例 a和案例 b根据JSON:API 规范都是有效的。

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

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

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

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

推荐阅读