Skip to content

Improvements related to ordering #416

@hhware

Description

@hhware

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 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. (Extracted into #473)

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, called order, to override the order of elements in the top-level data,
  • specify that if the member links.order is provided, then the order of elements in it overrides the ordering of elements of top-level data, otherwise ordering of elements in top-level data 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      pFad - Phonifier reborn

      Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

      Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


      Alternative Proxies:

      Alternative Proxy

      pFad Proxy

      pFad v3 Proxy

      pFad v4 Proxy