关系格式的JSON？

以关系格式序列化JSON有意义吗？例如，假设我在订单和OrderItem之间有一个多对多项目，订单之间共享许多项目。然后在JSON中，我可以在Order对象中只放置OrderItem id，然后在该对象下有一个包含扩展OrderItem对象的OrderItems列表。这样做的好处是我没有多余的数据，并且缩短了通过线路发送的数据量。另一方面，压缩算法可能会使这一点变得无关紧要，而且以后还要做更多的工作来扩展对象

---

只是想知道什么是标准实践：如果人们觉得JSON应该始终采用非规范化格式，或者关系格式有时是否有意义。假设后端有一个RDBMS。

我觉得这个问题的答案是一个经典的StackOverflow特例——“这取决于”

正如您所说，本文的主要重点是为视图返回数据，我将使返回的JSON负载包含呈现该视图所需的所有内容

这样做的好处是我没有多余的数据，并且我缩短了通过网络发送的数据量。另一方面，压缩算法可能会使这变得无关紧要，并且以后需要做更多的工作来扩展对象

是的，这取决于嵌入元素的“重量”。 如果您的视图包含许多不一定需要显示的“重”元素（用户也不介意等待这些细节出现），那么您当然可以返回该数据的标识符，以便（通过后续调用）返回

在本例中，您可以返回orderItems的精简版本，还可以选择使用一个链接来检索其完整详细信息

比如：

{
  "id": "1",
  "orderItems": [
    {
      "id": "a",
      "title": "A product",
      "fullDetails": "http://www.url.com/endpoint/order/1/items/a"
    },
    {
      "id": "b",
      "title": "Another product",
      "fullDetails": "http://www.url.com/endpoint/order/1/items/b"
    }
  ]
}

这几乎是哈提奥斯 使用HATEOAS，输出可以轻松确定如何与服务交互，而无需查找规范或其他外部文档，也无需嵌入整个文档

在您的案例中，另一个需要考虑的问题是缓存。 虽然我不知道您的域，但我怀疑订单及其OrderItems可能不会经常更改，但可能会被多次访问。 在本例中，您可以缓存（本地或服务器端）整个JSON文档，这将使下次检索相同数据更加高效

就我个人而言，我通常会返回视图模型，这些模型是当前视图的完整模型

HATEOAS上的一些链接

---

什么是上下文？您是否坚持使用文档存储/rdbms/将数据返回到视图？最初的重点是将数据返回到视图。非常有趣。我希望其他人也能发表评论。这种将其他JSON端点用于依赖对象的方法有多普遍？这种体系结构风格在其他地方有记录吗？我添加了一些HATEAOS上的墨迹HATEAOS的实际问题似乎是它会导致网络调用爆炸性增长。因此，您需要在浏览器端进行大量缓存。是否有（JavaScript）框架能够很好地支持在JSON中缓存依赖对象？以及刷新过时数据等等？这似乎是一个很大的领域，无论是现在还是将来。正如我在回答中所说，“诀窍”是，将JSON响应塑造为该视图的视图模型，以减少网络聊天-有许多方法可以缓存本地、本地和本地数据年龄应该是一个——我会调查一下——但这超出了您最初的问题的范围。我注意到，对于上面的orderItems，有一个id和一个指向fullDetails的链接。既然URI是唯一的，那么使用它作为id怎么样？这会更RESTful吗？