"Idempotency" of PATCH for the REST API

[amhn]

NetBox version

v3.5-beta

Feature type

Change to existing functionality

Proposed functionality

The different API endpoints for a model should accept/return the same Model[1].

For example it should be possible to use the output of GET /api/ipam/ip-addresses/1/ and either POST it to /api/ipam/ip-addresses/ or PATCH it to /api/ipam/ip-addresses/1/ and (if the new object does not violate uniqueness constraints) get an updated or new object.

[1] This does not mean read_only fields should become writable, read_only fields are already ignored most of the time on PATCH/POST requests.

Use case

This would make it easier for a new user to discover the API because he can just GET an existing object, modify some fields and POST/PATCH it to get the desired changes.

For script development this would also help, because the returned object can be the same as sent one.

Database changes

No response

External dependencies

No response

[amhn]

Currently I did identify 3 Problems:

• role field in Ipaddress is null on GET, but does not accept null on PATCH/POST. Filed as separate bug because this worked in 3.4. Ipaddress model does not accept null value for role, but serializer does (regression in 3.5-beta) #12195
• ChoiceFields are dicts in GET request, but strings in POST/PATCH. Handling them can be added to netbox.api.fields.ChoiceField without breaking existing behaviour
• Nested Object are already accepted, but read_only fields are not ignored. This can be added to netbox.api.serailizers.WritableNestedSerializer similar to ModelSerializer in django-rest-framework. That change should also be backwards compatible to existing behaviour.

I can work on the last two issues and provide a PR. This does not necessarily need to happen in the beta phase, because these changes should not affect the current documented behaviour.

Another thing is reflecting these changes in the API spec. But since the current documented behaviour is not affected, this could be added later.

[abhi1693]

Regarding the choice field, as a developer it makes the most sense to me the way it's working currently. Changing it to as mentioned will only cause confusion and it's unnecessary as the label in the dict cannot change in a post or patch. If a user tried to send a different label for an existing value, they would expect that to change but that's not possible.

[jeremystretch]

I'm fine with the proposed changes if they can be implemented in a manner that does not break backward compatibility. @amhn I'll assign this to you since you kindly offered to submit a PR; happy to provide any guidance.

[jeremystretch]

Closing this out as the assigned volunteer has not completed any work and there's been no further discussion.