JSON API Standard

Question

我怀疑在使用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: []

情况下)看起来语义,但在有效载荷中提供更多的信息情况b)是更快地得到我想要的作者(一个属性"用户名"，这是添加在附加属性:"authorName")，所以也不需要请求与前端的关联。

有什么更好的做法吗?为什么?

Answer 1

严格说来都情况下和案例b是有效的每个JSON API规范。

在的情况下，ausername是author资源的属性。在例b中authorName是resource1的属性。author资源在大小写b中也可能具有username属性。在这种情况下，你有重复的状态。

我建议只有在有充分理由的情况下才使用复制状态。重复状态增加了复杂性——无论是在服务器端还是在客户端。保持这两个属性同步需要付出高昂的代价。例如，你需要更新一个客户端，在一个成功的更新请求后，resource1发生了变化，这影响了author资源的username。客户端需要解析该响应并更新本地缓存。

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

试图减少有效负载大小几乎从来都不是接受增加复杂性的好理由。如果在网络级别考虑压缩和包的大小，那么原始有效负载大小通常不会产生太大的差异。