Removing slugs from the data model

[Jeremy Stretch]

Hi folks,

I'm hard at work on API 2.0 and lately I've been questioning the value of slugs in NetBox.

A slug field stores a simple, URL-friendly version of an object's proper name. For example, you might have a site named "DC1 (111 8th)" but it slug would be something like "dc1-111-8th" or just "dc1". The slug is then used to form a human-friendly URL (e.g. "/dcim/sites/dc1/") instead of needing to rely on the object's numerical ID (e.g. /dcim/sites/42/).

However, not all objects have slugs: devices, prefixes, IP addresses, vlans, etc. These objects cannot support a slug because they can't be normalized to a simple name. (Devices could be but we also have to support unnamed devices.) So, does it really make sense that we can go to /ipam/prefixes/1063/ to see a prefix but /ipam/rirs/arin/ to see a RIR?

Slugs are also used when filtering objects. For example, we can filter a list of VLANs by site by appending ?site=dc1 to the URL. The numeric primary key form is also available by appending _id to the field, e.g. ?site_id=123.

How would people feel about ditching slugs entirely and simply relying on the numeric ID for all objects?

Jeremy

[Patrick Fish]

I've adapted to using slugs for two use cases: hitting API endpoints from Python scripts, using URL shortener links to view a site or devices/circuits associated to a site.

Since all of my sites are already referenced internally as slugs, we use the same in Netbox. Most of our scripts take the slug as a parameter which in turn hits the Netbox API to get the information we need.

The scripts can be adapted to whatever change is needed, but we may lose the URL shortening ability to quickly pull up circuits/devices/prefixes/racks at $SLUG.

I'll support whatever the best path forward for Netbox is.

-Patrick

--
You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to netbox-discuss@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/CADvjYzoiLniWE6X363z9YyakF3nC4LN6wh0CWY0vfxOTsrgr_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Frank Pineau]

Each of my sites has a friendly name (the common name that techs use to refer to the site) as well as a unique three-letter code used in DNS entries and so forth. Lacking a better place to put them, I've been using the slug field. Although it's not completely suitable, it gets the job done. If you remove the field, I'd prefer to see a Site Code Ident field that could maybe display as a column in the Sites list.

[bellwood]

The only place im really using slugs is sites - where I store the IATA-3. If we ditch slugs could we have a field for either IATA-3 or CLLI codes?

As for URL friendliness, I'm fine with numeric representation.

[Brian Candler]

Another problem with slugs in netbox is that they're not unique by themselves.  For example: a rack group has a name and a slug, but I can have:

Site Foo, rack group Management

Site Bar, rack group Management

So any RESTful API which used slugs would have to have strict compound paths such as

/sites/foo/rack-groups/management/

/sites/bar/rack-groups/management/

i.e. the path requires both the site slug and the rack-group slug to select a single rack-group.  Any other object which referenced a rack-group would have to construct a hyperlink of similar form.

 

At this point, I think it's a lot simpler just to have /rack-groups/123/ and be done with it.

I also think it's not great practice to hard-code an *attribute* of an object as part of its *identity*.  Suppose in future you wanted to have a rack group which spanned sites, or was not associated with any site; you'd break the API.

Regards,

Brian.

[Alex Rodenberg]

We use it a lot in API calls, all our sites have the same "site code" as the slug, so we don't need to store an ID in our system to do a quick query on a site.

If the slugs disappeared there would be MANY places we had to do 1 call first to figure out what ID to look up.

It makes a lot of calls so much simpler.

[Josh VanDeraa]

I have to agree further with Alex as I've done more with the API in the past couple of days. The slug field as it is will be helpful to reduce it to the key site information that we can key in on.

--

You received this message because you are subscribed to the Google Groups "NetBox" group.
To unsubscribe from this group and stop receiving emails from it, send an email to netbox-discuss+unsubscribe@googlegroups.com.
To post to this group, send email to netbox-discuss@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/netbox-discuss/98552c63-9662-4ea0-8aa7-b70bba327acf%40googlegroups.com.