JSON data formatting

The TroopTrack Developer Program
1

I’m confused - sorry. I’m not an expert at JSON stuff but I’m learning. I don’t understand why some API calls give me back data formatted the way it is. For example, the award_types response is something like:

{
  "award_types": {
    "49": {
      "name": "Boomerang"
    },
    "54": {
      "name": "Achievement"
    },
(etc)
 }
}

Why is the “49” there like that? When I look at JSON tutorials it says it should look like this:

“employees”:[
{“firstName”:“John”, “lastName”:“Doe”},
{“firstName”:“Anna”, “lastName”:“Smith”},
{“firstName”:“Peter”,“lastName”:“Jones”}
]

When I copy the award_types response into a JSON to CSV or JSON to C# Class utility I get rubbish out - stuff like this:

public class __invalid_type__49
{
    public string name { get; set; }
}

public class __invalid_type__54
{
    public string name { get; set; }
}

The JSON to CSV converters usually give me back the whole dataset on one line with lots of columns.

I get that it is valid JSON - I’m just not sure why it’s being generated the way it is. It seems really hard (to my novice brain) to do anything much useful with it.

Other things work fine - user_achievements works exactly as I would expect and generates a sensible CSV file or C# class.

I’ve mostly got my solution working - I can query which parts of an award (Bronze/Silver/Gold Boomerang) all the Cubs have done - from this I generate a CSV file which does what I want except it’s missing the column headings (which come from the achievements API call.

If I could work out how to interpret the JSON output from “Award Types” & “Achievement” operations I’d be set.

1 Like
2

I can’t say for certain since I don’t work for TroopTrack, but the choice of the data for the Award Types example that you show is something I could guess.

The JSON choices seems very similar to variable types that I’ve seen on VBScript, JavaScript, and Python. I use Python mostly for my API calls. So, I’ll use the Python variable type names from there.

Python has both Lists and Dictionaries.

  • List is your basic array. It’s always contained in block parenthesis " [ ] " with a comma separating each entry.
  • Dictionaries are named arrays. That is, you have a string key that you use instead of an index. And you can add to them without worrying about indexes between.

In your example above, “award_types” is a key for the first dictionary. So, let’s say you stored that json inside the variable out. out[“award_types”] points to another dictionary with keys of “49”, “54”, etc. So, if you access the “49” key via out[“awards_types”][“49”], you’d get yet another dictionary with one key of “name”. So, to get the name, you’d access it via out[“awards_types”][“49”][“name”]. One other way to think of it is that JSON allows dictionaries of dictionaries, dictionaries of arrays, arrays of arrays or arrays of dictionaries. And this can be extended to any number of levels deep.

Now, to your question - Why format it this way? My only guess is that there could have been a need to extend the amount of data returned here. i.e. Say instead of just returning the “name”, they wanted to return a count of how many times this award is used in your troop. If it was just {“49”:“Boomerang”}, then you wouldn’t be able to extend “49” to have any other meanings. As it is today, you could easily add {“49” : {“name”:“Boomerang”, “used_count”:27}}

On the flip side, since there seems to be version control on the APIs (see v1 in the URL), I would think it doesn’t need any ability to extend. i.e. Once they come up with v2, they could completely change the return structure since you’d have to support v2 if you wanted to use it.

Hope it helps,
Steve

1 Like