-
Notifications
You must be signed in to change notification settings - Fork 890
Description
IMHO, not enough attention is given in the spec to the way of specifying of order of results in the response, especially given that the specification of sorting in the request is quite detailed. I believe it is just assumed that the way to specify order of results is to order elements in the top-level (Extracted into #473)data
, but AFAIK it is not mentioned explicitly anywhere. The only reference to ordering I was able to find is in the Recommendations: "because order is significant" . I suggest to mention this explicitly in the base spec.
Also, it has been repeatedly argued that streaming of data is one of viable use cases for JSON API. For example: Partitioning into types also introduces another layer of sorting on the server. When dealing with large result sets this increases latency as you can't send the response until you have fully processed the entire response. Howerver, if we extend this reasoning to requesting data in sorted form, streaming may become impossible if the sorting cannot be delegated to the data source (e.g., when the sorting rules are too complex to be implemented in SQL, or when the data source is not database but some other application which does not support sorting) -- the server-side application will have to fully process the entire response before starting to send it out.
I propose to modify the spec in two ways:
- allow an OPTIONAL member of top-level
links
, calledorder
, to override the order of elements in the top-leveldata
, - specify that if the member
links.order
is provided, then the order of elements in it overrides the ordering of elements of top-leveldata
, otherwise ordering of elements in top-leveldata
is used.
Definition of links.order
can be made identical to definition of relationship linkage of type data
:
{
"data": [{
"type": "articles",
"id": "12",
"attribute1": "value121",
"attribute2": "value122"
},{
"type": "comments",
"id": "34",
"attribute3": "value343",
"attribute4": "value344"
},{
"type": "comments",
"id": "56",
"attribute3": "value563",
"attribute4": "value564"
},{
"type": "articles",
"id": "78",
"attribute1": "value781",
"attribute2": "value782"
}],
"links": {
"order": [{
"type": "articles",
"id": "12"
},{
"type": "articles",
"id": "78",
},{
"type": "comments",
"id": "56"
},{
"type": "comments",
"id": "34"
}]
}
}
This way, the server-side application can start to stream data, determining order of elements of top-level data
on the go, and then return the computed order in the top-level links
in the end of transmission.
Any chance to still consider this before the spec hits 1.0?
I would be glad to promptly provide a PR for three proposed changes.