API call return data change

[sungod]

I noticed that some API calls have changed how they handle 'missing' data in the return values.

If a device did not have a name assigned, getNetworkDevices would not have a 'name' element in the return data, same for getDevice.

My scripts check for any devices with a missing 'name' element and substitute the MAC address to create a readable name that matches the Dashboard UI behaviour.

But that changed a couple of days ago...

Now the return value will (or may?) have a 'name' element, but it'll be empty, a Python None.

So my scripts started failing because 'name' was there, but rather than being a string value, the value is None (if no name was set.)

I'm updating scripts to cope with the new behaviour, I assume it's the result of the work to make API return data more consistent. It's a sensible change, better to have a None value than omit the 'name' element from results.

If you do similar checks for a potential missing 'name' element, time to check your code as obviously the problem only shows up where a device hasn't been named, which may come as a surprise!

[John_on_API]

Hi @sungod this is intentional -- we want to avoid the "missing keys" or "dynamic keys" problem by returning a consistent set of attributes whenever possible.

However, I saw you're using getNetworkDevices -- why use this instead of https://developer.cisco.com/meraki/api-v1/get-organization-devices/ ?

[sungod]

Would it be possible to give advance warning, or at least have a list of calls with modified return structures? At the moment the way I find out is when something breaks.

The calls used depend on exact context, so if it's just a single network or device, that call gets used rather than org-wide. Depends how ancient the script is as well 🙂