Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
eikef opened this issue Mar 30, 2021 · 0 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@eikef
Copy link

eikef commented Mar 30, 2021

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

@eikef eikef added the type: feature Introduction of new functionality to the application label Mar 30, 2021
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application and removed type: feature Introduction of new functionality to the application labels Apr 8, 2021
@jeremystretch jeremystretch self-assigned this Apr 8, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

2 participants