Skip to content
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

Accept nested parameters when setting related objects via the API #3077

Closed
jeremystretch opened this issue Apr 16, 2019 · 0 comments
Closed
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@jeremystretch
Copy link
Member

Environment

  • Python version: 3.5.6
  • NetBox version: 2.5.10

Proposed Functionality

I'd like to explore the possibility of accepting arbitrary parameters describing a related object as an alternative to providing the related object's unique primary key when when creating/updating objects via NetBox's REST API. For example, creating a device currently accepts a request like this:

POST /api/dcim/devices/
{
    "device_type": 123,
    "rack": 456,
    "name": "MyDevice",
    ...
}

This requires the client to have prior knowledge of the device type ID and the rack ID, which typically will require separate requests made earlier. It may be feasible to extend WritableNestedSerializer to alternatively accept nested parameters that can be converted to a queryset. For example:

POST /api/dcim/devices/
{
    "device_type": {
        "manufacturer": {
            "name": "Dell"
        },
        "model": "R640"
    },
    "rack": {
        "site": {
            "name": "Company HQ"
        },
        "name": "R104"
    },
    "name": "MyDevice",
    ...
}

The serializer for the device_type field would translate the provided JSON object into a queryset:

DeviceType.objects.get(manufacturer__name='Dell', model='R640')

The serializer would either assign the returned object to the field, or raise a validation error if the object is not found (or if multiple objects are found because the given attributes were not sufficiently unique).

The current behavior of accepting an integer primary key value will be retained as an alternative to this approach: Attributes will be evaluated only if the value provided for a field is a dictionary.

Use Case

Supporting this approach will obviate the need for precursory API queries to determine the primary key values of any related objects.

Database Changes

N/A

External Dependencies

N/A

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application API change labels Apr 16, 2019
@jeremystretch jeremystretch added this to the v2.6 milestone Apr 17, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jan 16, 2020
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: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

1 participant