Return the "request ID" change number when we do an API call

[apo51]

NetBox version

v3.0.7

Feature type

Change to existing functionality

Proposed functionality

Hello

When a change is done (PUT POST or DELETE) in Netbox via API, we would like to get the "request ID" change number in return.

Using it, it would be possible to do a rollback of a specific API call, especially when a change implies several changes logs :

Today we didn't find a way to associate an API call with a specific request ID (we only have the "time" but if we have 2 API calls really close, we don't know which one to pick in our pipelines) I didn't see any changes on this behavior in Netbox 3.1 in the datasheets (correct me if I'm wrong).

Thank you

Use case

When we do a change using the API, it would be very simple to retrieve all the changes done via the "request ID" and rollback them if necessary.

Database changes

No response

External dependencies

No response

[jeremystretch]

Disregarding for the moment the feasibility of securing the request ID for the response, how would you return the request ID? We probably want to avoid injecting into the actual API data to avoid a breaking change; would an HTTP header suffice?

[apo51]

Ideally, it would be better to retrieve it from the API datas. But if it's an issue for you, we can extract it from the HTTP header.

Maybe it could be added in the API in the future.

[kerryb48]

I was just researching if it was possible to get the request ID via the API response when I stumbled on this issue. We have interest in this, or similar feature as well, with the goal of being able to rollback/unwind requests associated with an overall user workflow/automation. I think returning it via HTTP header would be fine.

I thought of a potential alternate approach as well. Possibly slightly more complicated, but would serve my scenario well :)

Rather than returning the request ID via each individual API call - perhaps the API could be extended to allow the requestor to (optionally) include a unique ID in the X-Request-ID HTTP header when calling the Netbox API, and that X-Request-ID could then be associated/related to the netbox request ID. (ideally - would allow 1-to-Many)

A new API endpoint could be added to allow querying for all netbox request IDs associated with said X-Request-ID. This would give us a way to identify any/all changes made as part of a particular user request (even if that workflow invoked multiple CRUD actions on the netbox API).

I am pretty new to Netbox, so I wont pretend to know whether or not this would be more difficult than securing the request ID for the API response, but thought I'd at least throw it out there!

[jeremystretch]

I suppose it would be necessary to return the change record ID inline with the data to support multi-object operations (e.g. bulk creation).

However, I don't think this is feasible given that the creation of the change record is queued for processing after the response has been generated.

[baldgeek]

Is there a way to get creative? Can it return a unique value for in the queue that a second API call could use to get the change record ID(or something along the lines it isn't processed yet)

On 4/6/22 16:27, Jeremy Stretch wrote:

I suppose it would be necessary to return the change record ID inline with the data to support multi-object operations (e.g. bulk creation).

However, I don't think this is feasible given that the creation of the change record is queued for processing /after/ the response has been generated.

— Reply to this email directly, view it on GitHub https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnetbox-community%2Fnetbox%2Fissues%2F8422%23issuecomment-1090753788&data=04%7C01%7Cjos100%40psu.edu%7C3c45fccd8a4549573f7408da180bdb88%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637848736445591691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=c2Xbn%2Bww79XgfTa60Lo0x0P9GmubAwmj3AHzZ8Yhs7g%3D&reserved=0, or unsubscribe https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANYW3MID2CLGSCS5TRE2HADVDXXSVANCNFSM5MPE6JZQ&data=04%7C01%7Cjos100%40psu.edu%7C3c45fccd8a4549573f7408da180bdb88%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637848736445591691%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ziggin8T6yPOAIfDV9sh1vbEc2o2yutQKlGNBTDciAM%3D&reserved=0. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jeremystretch]

You're certainly welcome to experiment with potential solutions, but I'd expect that any such workarounds are going to be a bigger headache than simply querying for most recent change log for the object.

[github-actions[bot]]

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. Please see our contributing guide.

[github-actions[bot]]

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.