Wildly different data in the same key

[Bob_Zimmerman]

I posted about this over on CPUG, but thought I should post here as well. In working with the API on R80.40 jumbo 77, I have noticed certain calls return a dictionary with the same keys, but with wildly different data inside some of these keys. I first noticed it with groups:

[Expert@SmartCenter]# mgmt_cli -r true show object uid "2a469820-b502-434c-9340-a377677a6a60" --format json details-level full
{
  "object" : {
    "uid" : "2a469820-b502-434c-9340-a377677a6a60",
    "name" : "CIFS",
    "type" : "service-group",
    ...,
    "members" : [ {
      ...
    }, {
      "uid" : "97aeb471-9aea-11d5-bd16-0090272ccb30",
      "name" : "NBT",
      ...,
      "members" : [ "97aeb414-9aea-11d5-bd16-0090272ccb30", "97aeb415-9aea-11d5-bd16-0090272ccb30", "97aeb416-9aea-11d5-bd16-0090272ccb30" ],
      ...
    } ],
    ...
  }
}

Note that the top-level 'members' key contains a list of dictionaries, but the inner 'members' key contains a list of strings. To deal with this, I have to manually override my language's JSON decoder and attempt to decode as a list of dictionaries and as a list of strings, then go from whichever one works to my internal data type. This is an enormous headache, but at least I can get the members' UUIDs from either and use that to figure everything out.

It gets worse:

[Expert@SmartCenter]# mgmt_cli -r true show objects offset 3000 limit 500 --format json details-level full
{
  "from" : 3001,
  "to" : 3500,
  "total" : 8960,
  "objects" : [ ...
  }, {
    "uid" : "4d25f6a9-e99a-ce43-a6ce-27a8280d918f",
    "name" : "SmartCenter",
    "type" : "simple-gateway",
    ...,
    "interfaces" : [ {
      "name" : "eth1",
      "ipv4-address" : "10.20.30.40",
      "ipv4-network-mask" : "255.255.255.0",
      "ipv4-mask-length" : 24,
      "ipv6-address" : "",
      "comments" : "",
      "color" : "black",
      "icon" : "NetworkObjects/network",
      "topology" : "automatic",
      "topology-automatic-calculation" : "internal",
      "topology-settings" : {
        "ip-address-behind-this-interface" : "not defined",
        "interface-leads-to-dmz" : false
      },
      "anti-spoofing" : false,
      "security-zone" : false
    } ],
    ...
  }, {
  ...
  } ]
}

[Expert@SmartCenter]# mgmt_cli -r true show gateways-and-servers --format json details-level full
{
  "objects" : [ {
    "uid" : "4d25f6a9-e99a-ce43-a6ce-27a8280d918f",
    "name" : "SmartCenter",
    "type" : "simple-gateway",
    ...,
    "interfaces" : [ {
      "interface-name" : "eth1",
      "ipv4-address" : "10.20.30.40",
      "ipv4-network-mask" : "255.255.255.0",
      "ipv4-mask-length" : 24,
      "dynamic-ip" : false,
      "topology" : {
        "leads-to-internet" : false,
        "ip-address-behind-this-interface" : "not defined",
        "leads-to-dmz" : false
      }
    } ],
    ...
  } ],
  "from" : 1,
  "to" : 1,
  "total" : 1
}

"topology" again switches between a string and a dictionary, but neither value can be derived from the other. Other values in the interface dictionary have wildly different key names. And each version of the interface dictionary has data the other doesn't, so you have to get both personalities of the interface and merge them to get all the data.

This seems bad.

[PhoneBoy]

If I'm understanding your complaint properly, show objects and show gateways-and-servers return different data for the same object.
Not sure if this is the intended behavior or not.
Paging @Omer_Kleinstern 

[Bob_Zimmerman]

That's part of it, but even entirely within 'show objects', the 'members' key of an object can contain either a list of dictionaries or a list of strings. This seems like the kind of thing the objects-dictionary key is for when viewing rules. I realize it would be a little weird to include an objects-dictionary when you're already viewing objects, but it would be nice to have a parameter I could pass in my API call to get only UUID strings in any field which contains objects.

Edited to add: Or, put another way, I need a way for the data I get from the API to be consistent. Every single 'members' field should contain either full objects or a list of object UUIDs. A parameter to pick which one you want the API to give you would be nice, but the API as a whole needs to pick one of them to return. The interfaces list needs to always contain objects with the same schema. I'm not sure yet where else might return inconsistent data.