OpenAPI Spec not matching observed behaviour for Interface Model

[mytlogos]

NetBox version

v.3.6.1

Python version

3.8

Steps to Reproduce

1. Create wlan
2. Create device with wlan interface
3. "Connect" wlan interface to wlan (Select wlan from edit form)
4. request the interfaces endpoint (all or just one) (curl -v -s -H "Authorization: Token $TOKEN" http://netbox/api/dcim/interfaces/)

Expected Behavior

According to the OpenAPI spec, the Interface Model returns an array of integers.
See https://demo.netbox.dev/api/schema/swagger-ui/#/dcim/dcim_interfaces_list

Observed Behavior

The InterfaceSerializer returns the full objects instead of the expected wlan ids.

This is more useful as an api itself, but openapi generators which consume this api spec (e.g. https://github.com/OpenAPITools/openapi-generator/), generate wrong client implementations leading to unexpected behaviour.

In my case i used openapi generator to generate a golang client for netbox 3.6.1 (the official go-netbox client is still stuck at 3.4: netbox-community/go-netbox#157).
Assigning a wlan to an interface in netbox lead to golang unmarshalling an empty interface struct due to unexpected values in the response (a struct/object instead of integers), where it fails silently for some reason.

Unassigning the wlan from the interface "fixes" this bug.

[abhi1693]

I'd say the observed behaviour is the correct one if it returns the list of objects. We should rather fix the openapi specifications

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[github-actions]

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.