OpenAPI schema is incorrect for the `ipam_prefixes_available-prefixes_create` endpoint

[Gaardsholt]

NetBox version

v3.4.5-dev

Python version

3.9

Steps to Reproduce

1. Open the API docs at /api/docs/
2. Find the /ipam/prefixes/{id}/available-prefixes/endpoint
3. See that it says that you can only specify the prefix_length in the body

Expected Behavior

That I can use all the fields set on a prefix.

I have successfully tested with the following fields:

{
  "prefix_length": 0,
  "site": 0,
  "role": 0,
  "tenant": 0,
  "vrf": 0,
  "vlan": 0,
  "status": "container",
  "is_pool": true,
  "mark_utilized": true,
  "description": "string",
  "comments": "string"
}

Observed Behavior

That the API docs shows all the available fields that I can set.

I have been playing around with it locally, so I will be happy to do a pull request for it.

[arthanson]

This looks like it is still an issue for OpenAPI 3, but blocked till #9608 gets in.

[arthanson]

@Gaardsholt I don't think this is actually a bug. prefix_length is the only valid field to pass for available_prefixes. By default DRF (which is used to create the API endpoints) by default doesn't error on extra fields passed in (see: https://stackoverflow.com/questions/22178266/django-rest-framework-raise-error-when-extra-fields-are-present-on-post). You could open a feature request to enable this (but should be done on all APIs, not just this one) if this is a problem. Closing for now.

[Gaardsholt]

@arthanson I guess it shouldn't error on the extra fields?
Because when I set those extra fields, they are applied, so it has to be a bug in the API schema, right?

[kkthxbye-code]

@arthanson

prefix_length is the only valid field to pass for available_prefixes.

As Gaardsholt said this is incorrect. available_prefixes accepts and persists all prefix fields as far as I can tell.

Simple payload as this shows it:

https://demo.netbox.dev/api/ipam/prefixes/98/available-prefixes/

{
  "prefix_length": 30,
  "description": "test"
}

[jeremystretch]

I think this was my mistake. I told @arthanson that PrefixLengthSerializer only accepts a prefix_length field (which is technically true, hence the bug), but it also passes other data into the Prefix instance. Ultimately the serializer itself really should be rebuilt more cleanly.