starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

REST API: dcim/interfaces has count_ipaddresses, while virtualization/interfaces does not #4710

New Issue
Closed
opened 2025-12-29 19:19:42 +01:00 by adam · 0 comments
adam commented 2025-12-29 19:19:42 +01:00
Owner
Copy Link

Originally created by @eikef on GitHub (Mar 30, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v2.10.6

Feature type

Change to existing functionality

Proposed functionality

Currently the /api/dcim/interfaces-endpoint provides a convenient read-only count_ipaddresses field in its return, whereas the /api/virtualization/interfaces-endpoint does not -- although the latter can have IP addresses assigned just like the former and is otherwise very similar in its usage.

I would propose the count_ipaddresses-field to be exposed via the REST API for /api/virtualization/interfaces the same as it is now for /api/dcim/interfaces, for both consistency and utility; if that is not indended, then maybe the count_ipaddresses-field should be deprecated on /api/dcim/interfaces so one does not get bitten by assuming it to be there when using both APIs in similar code.

Use case

Consistency in the API between /api/dcim/interfaces and /api/virtualization/interfaces; personally was surprised when the field was unavailable in one but not the other.

There is utility in the count_ipaddresses field in that it can save unnecessary API calls.

Database changes

No response

External dependencies

No response

Originally created by @eikef on GitHub (Mar 30, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v2.10.6 ### Feature type Change to existing functionality ### Proposed functionality Currently the `/api/dcim/interfaces`-endpoint provides a convenient read-only `count_ipaddresses` field in its return, whereas the `/api/virtualization/interfaces`-endpoint does not -- although the latter can have IP addresses assigned just like the former and is otherwise very similar in its usage. I would propose the `count_ipaddresses`-field to be exposed via the REST API for `/api/virtualization/interfaces` the same as it is now for `/api/dcim/interfaces`, for both consistency and utility; if that is not indended, then maybe the `count_ipaddresses`-field should be deprecated on `/api/dcim/interfaces` so one does not get bitten by assuming it to be there when using both APIs in similar code. ### Use case Consistency in the API between `/api/dcim/interfaces` and `/api/virtualization/interfaces`; personally was surprised when the field was unavailable in one but not the other. There is utility in the `count_ipaddresses` field in that it can save unnecessary API calls. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: bugstatus: accepted labels 2025-12-29 19:19:42 +01:00
adam closed this issue 2025-12-29 19:19:42 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#4710
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?