API Groovy HttpPatch?
Is it possible to do an HttpPatch, or to use the PATCH verb, when updating devices?
I looked over on one of the LM pages for updataing devices with the API and as usual, most of the examples were in Python, but PUT did have one Groovy example, but PATCH did not. I’ve seen mention somewhere that at some point PATCH would be supported, wondering if it is or not.
I ended up getting my script working with a Get (so I dont lose all my device custom settings etc) and then changing the autoBalancedCollectorGroupId value, and then doing a PUT and it worked, and I didnt lose any of my custom properties. And I have a working filter all set up to run it against a target set of devices.
But still, I would rather just patch the fields I want without risk. I’m wondering if thats possible, or if GET/tweak/PUT is still the main go-to?
LM User
·2 years agoUp to personal preference at that point. It should work either way since you already have the object in memory. Technically, it’s a bit less efficient to do a PUT since you’re putting more data than what needs to be changed, but the PUT also doesn’t change anything if nothing needs to be changed.
I personally would do PATCH because that way i know my code is only touching the thing i want to change (easier to tell what the code is changing). PUT is technically more idempotent.
Lewis_Beard
OP2 years agoOh and, while I may go ahead and try the patch option, generally speaking, since my GET was actually with a filter looking for autoBalancedCollectorGroupId:0 as well as a target collector group in the filter, I’m already doing a GET that gives me all the objects back and I have their json data in memory.
So at that point, what are the cons of using a PUT given that I already have the object, can just change the value in the JSON, prep the data for the PUT, and do the PUT. Is it problematic or is PATCH still the way to go, assuming I can get it working?
LM User
·2 years agoYou got lucky dodging a bullet. If you don’t specify the customProperties element in your json payload, the optype isn’t required, since it only applies to them. Though i’ve seen apparently inconsistent behavior when requiring the optype, maybe that was the SDK.
Lewis_Beard
OP2 years agoI will bookmark it too.
The interesting thing is that my initial code was in Python, before I decided “nah, its time to go all-in on the Groovy” and I did a patch without specifying opType=replace, but it didnt reset any of my custom properties or anything, but it did update the autobalance as I expected.
Not sure if I dodged a bullet there or just got lucky. :)
Thanks!
LM User
·2 years agoHehe, i keep that page bookmarked because it’s the only place i’ve found that describes it.
LM User
·2 years agohttps://www.logicmonitor.com/support/rest-api-developers-guide/v1/devices/update-a-device#:~:text=Define%20custom%20properties%20for%20this%20device.%20Each%20property%20needs%20to%20have%20a%20name%20and%20a%20value.%20To%20add%20or%20update%20just%20one%20or%20a%20few%20device%20properties%20in%20the%20customProperties%20object%2C%20but%20not%20all%20of%20them%2C%20you%E2%80%99ll%20need%20to%20additionally%20use%20the%20opType%20query%20parameter.%20The%20opType%20query%20parameter%20can%20be%20set%20to
It’s not in the swagger docs (which are automatically generated and don’t contain any helpful information like that unless the devs decided to add it; surprse, they didn’t).
Lewis_Beard
OP2 years agoI am curious where that documentation was, that you quoted. I went to the link you sent, but I couldnt find that anywhere. I DID FIND the Patch section for devices, and I see the opType …. if you hadnt pointed out the differences between refresh (default) and replace, I might have tried it and been regretful. :)
https://www.logicmonitor.com/support/rest-api-developers-guide/v1/devices/update-a-device
The only reason I did the GET-tweak-PUT is because the groovy code didnt give a patch example.
I DID manage to get Python code on my own working with patch before even looking at the link above, but I am moving away from doing anything in Python if possible, because I’d like to stick to code that is native to the portal (Groovy, Powershell).
Thanks for the response! I’ll see if I can get Patch to work with the opType set to the correct thing, and I’ll export my target device as I try it.
Cheers!
LM User
·2 years agoIt depends on the endpoint. Look it up in the swagger docs and see if there’s a patch option. There usually is. The key with patch is that LM wants you to include an opType query parameter, and it’s not clear what this does. Here’s the best documentation I could find:
Here’s my understanding:
It only has anything to do with patching the custom properties.
opType=add - this will add any new properties you have specified in the customProperties of your payload. New properties will be added. Existing properties will remain with their existing value for any properties that already exist that are specified in your payload. I don’t see the use case for this one and don’t use it.
opType=replace - this will add any new properties you have specified in the customProperties of your payload. New properties will be added. Existing properties will be overwritten with the value for that property in your payload. This one makes the most sense to me as it updates/creates the properties i specify in my payload and leaves everything else alone. This is the one i use almost exclusively.
opType=refresh - this is the nuclear option. This deletes all custom properties and adds the ones from your payload. This one is the most dangerous and is more like a PUT. Exactly like a PUT actually, but only when it comes to the customProperties. So it’s like PATCHing the device, but PUTting the customProperties.
GET-tweak-PUT should not be the go-to.