Does it make sense to serialize JSON in relational format? E.g. suppose I have a many-to-many between Order and OrderItem, with many items being shared between orders. Then in the JSON I could put just the OrderItem id's in the Order object, then under that have a list of OrderItems with the expanded OrderItem objects. The advantage of this is that I don't have redundant data and I shorten the amount of data sent over the wire. On the other hand, compression algorithms might make this irrelevant, and there is more work to do expanding out the objects afterwards.
Just wondering what is standard practice: if people feel that JSON should always be in denormalized format, or if a relational format can sometimes make sense. Assume an RDBMS on the backend.
I feel that the answer to this question, is a classic StackOverflow-special - “it depends"
As you said, the primary focus for this is returning data for a view, I would make the returned JSON payload contain everything needed to render that view.
The advantage of this is that I don't have redundant data and I shorten the amount of data sent over the wire. On the other hand, compression algorithms might make this irrelevant, and there is more work to do expanding out the objects afterwards.
Yes, this dependent on how “heavy” the embedded elements are, however. If your view contains many “heavy” elements, that are not always required to be shown (and the user would not mind waiting for these details to appear) then you could of course return an identifier for that data, to be returned (by subsequent call)
In this instance, you could return a cut down version of orderItems, optionally with a link to retrieve their full details.
Something like:
{
"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"
}
]
}
This is bordering on HATEOAS With HATEOAS, the output makes it easy to figure out how to interact with the service without looking up a specification or other external document, or embedding the entire document
Another consideration in your case, is caching. Although I don’t know your domain, I suspect that Orders and their OrderItems may not change often, but may be accessed several times. In this instance, you can cache (locally, or server side) the whole JSON document, which would make retrieving the same data next time a lot more efficient.
Personally, I would usually return view models that are a full model of the current view.
Some links on HATEOAS
http://spring.io/understanding/HATEOAS
http://timelessrepo.com/haters-gonna-hateoas
https://blog.apigee.com/detail/api_design_honing_in_on_hateoas