Ticket Created
over 3 years ago

CIQQA-903

Processing JSON with missing root

The following (which is valid JSON) returns  INVALID_HTTP_BODY_IN_NETWORK_RESPONSE.

It's missing the root node but is still valid JSON. Missing the root node is fairy common. So, it should be able to be processed by IQ.

[
{
"name":"aaaa"
},
{
"name":"bbbb"
}
]

The following  is not missing the root node (and works).

 

{
"list" : [
{
"name":"aaaa"
},
{
"name":"bbbb"
}
]
}

dpawlyk
Parents
  • over 3 years ago in reply to dpawlyk

    > The issue is missing the key in the root. Not in other levels.
    > It's fairly common to be missing the key at the root.

    The JSON format requires JSON Object keys to be String. Additionally, the null object is of type Null. Since String and Null are not the same type, it is not legal for null to be a key. You can read the JSON standard here. It is short and quite simple.

    https://www.ecma-international.org/wp-content/uploads/ECMA-404_2nd_edition_december_2017.pdf

    Even if null could be a key, there is a big difference between a null key and omitting the key, which it seems is what you believe is happening.

    The difference between the snips in the original post is *not* that the key is null in one and the empty string in the other.

    The first snip shows is an JSON Array of JSON Object. The second is a JSON Object with a key/value pair that has a value that is an Array of JSON Object. The types are very different from both a JSON perspective and a ConnectIQ perspective.

    > It's common for consumers to deal with it. It's Garmin being odd man out.

    As I said in my original response, we (ConnectIQ) require the HTTP response body to contain a well formed JSON Object (a Dictionary). Some services generate HTTP responses that are valid JSON Values (any of JSON Object, Array, Number, String, true, false, or null). This means that ConnectIQ accepts only a subset of the types produced by some web services.

    As I said in my original response, this is something we know. The issue has come up several times and has not been fixed. There are existing tickets in our backlog for it, but I don't have any reason to believe that the will be fixed soon.

Comment
  • over 3 years ago in reply to dpawlyk

    > The issue is missing the key in the root. Not in other levels.
    > It's fairly common to be missing the key at the root.

    The JSON format requires JSON Object keys to be String. Additionally, the null object is of type Null. Since String and Null are not the same type, it is not legal for null to be a key. You can read the JSON standard here. It is short and quite simple.

    https://www.ecma-international.org/wp-content/uploads/ECMA-404_2nd_edition_december_2017.pdf

    Even if null could be a key, there is a big difference between a null key and omitting the key, which it seems is what you believe is happening.

    The difference between the snips in the original post is *not* that the key is null in one and the empty string in the other.

    The first snip shows is an JSON Array of JSON Object. The second is a JSON Object with a key/value pair that has a value that is an Array of JSON Object. The types are very different from both a JSON perspective and a ConnectIQ perspective.

    > It's common for consumers to deal with it. It's Garmin being odd man out.

    As I said in my original response, we (ConnectIQ) require the HTTP response body to contain a well formed JSON Object (a Dictionary). Some services generate HTTP responses that are valid JSON Values (any of JSON Object, Array, Number, String, true, false, or null). This means that ConnectIQ accepts only a subset of the types produced by some web services.

    As I said in my original response, this is something we know. The issue has come up several times and has not been fixed. There are existing tickets in our backlog for it, but I don't have any reason to believe that the will be fixed soon.

Children
No Data