Devices API only location_id parameter and no location

[bluikko]

I was shocked to find out that the dcim/devices API only has a location_id parameter and no location parameter.
I wonder why is that - performance, oversight?

Am I really the only one who would want to query devices based on location? The external systems have no knowledge of any IDs; of course I could first resolve the location to ID but it is quite a surprising requirement.

[candlerb]

Shocked, I tell you, shocked! :-)

The queries you can use (in Netbox v3.4.5) are defined here: https://github.com/netbox-community/netbox/blob/v3.4.5/netbox/dcim/filtersets.py#L793-L970

location_id is a TreeNodeMultipleChoiceFilter, so I imagine it's an implementation limitation that this works with IDs directly, not an indirect reference like location name or slug.

of course I could first resolve the location to ID but it is quite a surprising requirement.

I'm never surprised by how bad REST APIs are, or their documentation. I only ever used one which had half-decent documentation, and that was Salesforce.

[jeremystretch]

I wonder why is that - performance, oversight?

It's a safeguard. Location names and slugs aren't globally unique, so querying for e.g. ?location=room101 would match all locations with the slug room101 across all sites, which is probably not what you want.

[candlerb]

Although some time ago there was a separate discussion as to whether slugs should be unique across a particular class of object: #8113

Locations are a special case in that they form a tree, and slug uniqueness is only enforced between siblings of the same parent (or in the same site, if they have no parent location). This makes the slug not very useful.

[jeremystretch]

Locations aren't unique in this respect; all such nested models employ non-unique slugs: regions, site groups, contact groups, tenant groups, and wireless LAN groups. I've advocated for removing slugs altogether under #8113 but people are attached to them.

[candlerb]

My position was: keep them, make them nullable, but globally unique if not null.

That way, anyone who doesn't want them, sets them to null (which can be the default). And people who want to use them, get them as unique keys, such that queries like location=foo are useful.

[bluikko]

People are attached to them because they are useful.