Problem/Motivation

Doing the same request does not result in same json key order. So visual comparing or git diff is not really working out.

curl --header 'Accept: application/vnd.api+json' --request GET http://drupal.d8/jsonapi/node/article | json_pp  

{
   "links" : {
      "self" : "http://drupal.d8/jsonapi/node/article"
   },
   "data" : [
      {
...
         "type" : "node--article",
         "attributes" : {
            "uuid" : "e1fea20c-8e3e-46de-9d01-037c84cf060b",
            "created" : 1496067707,
            "comment" : {
               "last_comment_timestamp" : 1496067714,
               "cid" : 0,
               "comment_count" : 0,
               "last_comment_name" : null,
               "status" : 2,
               "last_comment_uid" : 1
            },
            "revision_translation_affected" : true,
            "title" : "Article 1",
...
            "status" : true,
            "sticky" : false
         }
      }
   ],
   "meta" : {
      "errors" : [

Proposed resolution

It would be nice to have ALL keys sorted recursively. It that possible?

Remaining tasks

User interface changes

API changes

Data model changes

Comments

clemens.tolboom created an issue. See original summary.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Priority: Normal » Minor

This would likely help #2930028: Comprehensive JSON API integration test coverage phase 1: for every entity type, individual resources only.

dawehner’s picture

dawehner
Primary language German
commented
Issue tags: +DX (Developer Experience)

Is this a system the serializer system itself could have? One could see this not as a feature of json api itself but rather the more generic serializer system.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Interesting idea!

I guess that one downside would be that the current ordering of fields and properties roughly matches a "logical" order. id and uuid come first, for example, in json, xml and hal_json, before other fields.
And for JSON API, links would no longer be at the top, data would be.

I don't think that either one is a problem. But the question is: is that then still an improvement? Aren't we changing responses and doing more computations just for an esoteric use case? (Visual comparing or git diff.) Shouldn't those use cases do the sorting themselves?

In \Drupal\Tests\rest\Functional\EntityResource\EntityResourceTestBase(), we have this a bunch of times:

    $expected = $this->getExpectedNormalizedEntity();
    static::recursiveKSort($expected);
    $actual = $this->serializer->decode((string) $response->getBody(), static::$format);
    static::recursiveKSort($actual);
    $this->assertSame($expected, $actual);

We could remove that. But see, that's once again an esoteric use case: test coverage. Currently the burden is on the test coverage.

I'm not sure yet what we should do, but I definitely think this should remain Minor.

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented
Status: Active » Closed (works as designed)

From http://json.org/

An object is an unordered set of name/value pairs. An object begins with { (left brace) and ends with } (right brace). Each name is followed by : (colon) and the name/value pairs are separated by , (comma).

This clearly indicates that regardless of the particular implementation (in our case json_encode()) members of an object are considered unordered. To me this tells me that whatever order is OK, no need to sort.