API variable type mismatch at creating/modifying an entry

[tatsushid]

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 7241783, 821fb1e 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.

[jeremystretch]

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.

[tatsushid]

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.

[sdktr]

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)?

[tatsushid]

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.

[jeremystretch]

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.