以关系格式序列化JSON是否有意义?例如。假设我在Order和OrderItem之间有多对多,订单之间共享许多项目。然后在JSON中我可以将OrderItem id放在Order对象中,然后在其下面有一个OrderItems列表和扩展的OrderItem对象。这样做的好处是我没有冗余数据,而且我缩短了通过线路发送的数据量。另一方面,压缩算法可能会使这无关紧要,之后还需要做更多工作来扩展对象。
只是想知道什么是标准做法:如果人们认为JSON应该总是采用非规范化格式,或者关系格式有时是有意义的。假设后端有一个RDBMS。
答案 0 :(得分:3)
我觉得这个问题的答案是经典的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接壤 使用HATEOAS,输出可以轻松找出如何与服务进行交互,而无需查找规范或其他外部文档,或嵌入整个文档
您的案例中的另一个考虑因素是缓存。 虽然我不知道您的域名,但我怀疑Orders及其OrderItems可能不会经常更改,但可能会多次访问。 在这种情况下,您可以缓存(本地或服务器端)整个JSON文档,这将使下次检索相同的数据效率更高。
就个人而言,我通常会返回视图模型,它们是当前视图的完整模型。
HATEOAS上的一些链接
http://spring.io/understanding/HATEOAS
http://timelessrepo.com/haters-gonna-hateoas
https://blog.apigee.com/detail/api_design_honing_in_on_hateoas