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

API variable type mismatch at creating/modifying an entry #1980

New Issue
Closed
opened 2025-12-29 17:21:06 +01:00 by adam · 5 comments
adam commented 2025-12-29 17:21:06 +01:00
Owner
Copy Link

Originally created by @tatsushid on GitHub (Aug 30, 2018).

Environment

  • Python version: 3.5.2
  • NetBox version: 2.4.3

Steps to Reproduce

  1. Open /api/docs/ URL of NetBox
  2. For example, open POST /ipam/ip-addresses/
  3. It shows 
    tenant: {
    id: integer ...,
    url: string ...,
    name: string ...,
    slug: string ...
}

Expected Behavior

In the example above, it should be

tenant: integer ...

Observed Behavior

It shows a parameter which is only compatible at reading but incompatible at writing like

tenant: {
    id: integer ...,
    url: string ...,
    name: string ...,
    slug: string ...
}

Details

Thanks for providing a great software! I'm enjoy using it.

After upgrading to 2.4.3, I found all "WritableXXX" data models had gone away from API JSON representation taken from /api/docs/?format=openapi and these had been replaced by models which were used at reading (GET request). It causes API document mismatch with NetBox internal behavior and a generated code by Swagger doesn't work especially in static type system language like Go etc.

In the above, I explain about a tenant parameter but there are some other parameters which have the same issue.

As far as I checked, it seems to have been introduced at commit 72417832, 821fb1e0 etc. I think a solution should be

  • Change API JSON description at POST, PUT etc. if a parameter inherits WritableNestedSerializer
  • Just allow a reading parameter and ignore unneeded arguments at writing

I'm not much familiar with Python so the ideas are just my thought.

Originally created by @tatsushid on GitHub (Aug 30, 2018). ### Environment * Python version: 3.5.2 * NetBox version: 2.4.3 ### Steps to Reproduce 1. Open `/api/docs/` URL of NetBox 2. For example, open `POST /ipam/ip-addresses/` 3. It shows ``` tenant: { id: integer ..., url: string ..., name: string ..., slug: string ... } ``` ### Expected Behavior In the example above, it should be ``` tenant: integer ... ``` ### Observed Behavior It shows a parameter which is only compatible at reading but incompatible at writing like ``` tenant: { id: integer ..., url: string ..., name: string ..., slug: string ... } ``` ### Details Thanks for providing a great software! I'm enjoy using it. After upgrading to 2.4.3, I found all "WritableXXX" data models had gone away from API JSON representation taken from `/api/docs/?format=openapi` and these had been replaced by models which were used at reading (GET request). It causes API document mismatch with NetBox internal behavior and a generated code by Swagger doesn't work especially in static type system language like Go etc. In the above, I explain about a `tenant` parameter but there are some other parameters which have the same issue. As far as I checked, it seems to have been introduced at commit 72417832, 821fb1e0 etc. I think a solution should be - Change API JSON description at POST, PUT etc. if a parameter inherits `WritableNestedSerializer` - Just allow a reading parameter and ignore unneeded arguments at writing I'm not much familiar with Python so the ideas are just my thought.
adam added the type: documentation label 2025-12-29 17:21:06 +01:00
adam closed this issue 2025-12-29 17:21:06 +01:00
adam commented 2025-12-29 17:21:07 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 4, 2018):

The API documentation is generated automatically using drf-yasg. If someone can come up with a non-intrusive way of enabling Swagger to recognize the different read/write behaviors, I'll be happy to incorporate it.

@jeremystretch commented on GitHub (Sep 4, 2018): The API documentation is generated automatically using [drf-yasg](https://github.com/axnsan12/drf-yasg). If someone can come up with a non-intrusive way of enabling Swagger to recognize the different read/write behaviors, I'll be happy to incorporate it.
adam commented 2025-12-29 17:21:07 +01:00
Author
Owner
Copy Link

@tatsushid commented on GitHub (Sep 14, 2018):

I've written a fix and tested it in our system. It passed unit tests and worked with our API client written in Go. I'll send a pull-request once I clean up commits. Let's discuss about the implementation there.

@tatsushid commented on GitHub (Sep 14, 2018): I've written a fix and tested it in our system. It passed unit tests and worked with our API client written in Go. I'll send a pull-request once I clean up commits. Let's discuss about the implementation there.
adam commented 2025-12-29 17:21:07 +01:00
Author
Owner
Copy Link

@sdktr commented on GitHub (Oct 18, 2018):

and worked with our API client written in Go.

Is that a swagger/openapi auto generated client? In other words: does your fix apply to other places where this behavior is observed (and other swagger based clients)?

@sdktr commented on GitHub (Oct 18, 2018): > and worked with our API client written in Go. Is that a swagger/openapi auto generated client? In other words: does your fix apply to other places where this behavior is observed (and other swagger based clients)?
adam commented 2025-12-29 17:21:07 +01:00
Author
Owner
Copy Link

@tatsushid commented on GitHub (Oct 19, 2018):

Yes, it is generated from the swagger definition.

My purpose of the patch is generating swagger definition properly especially for a static type language and using it in my client. I've written it for NetBox 2.4.4, applied to it, downloaded swagger definition and generated a Go client library by go-swagger from it.

@tatsushid commented on GitHub (Oct 19, 2018): Yes, it is generated from the swagger definition. My purpose of the patch is generating swagger definition properly especially for a static type language and using it in my client. I've written it for NetBox 2.4.4, applied to it, downloaded swagger definition and generated a Go client library by go-swagger from it.
adam commented 2025-12-29 17:21:07 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 5, 2018):

Django REST Framework 3.9 now includes native OpenAPI schema support. I haven't had a chance to dig into it yet, but we might end up ditching Swagger entirely in favor of the native implementation.

@jeremystretch commented on GitHub (Nov 5, 2018): Django REST Framework 3.9 now includes [native OpenAPI schema support](https://www.django-rest-framework.org/community/3.9-announcement/#built-in-openapi-schema-support). I haven't had a chance to dig into it yet, but we might end up ditching Swagger entirely in favor of the native implementation.
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 type: documentation
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#1980
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?