I’m working with an HTTP library that does not support PATCH but want to send an update meeting request. I may have no choice but to do a delete and create but before I code that I wanted to check if the ZOOM Rest API supports anything to work around that.
I’ve read that some APIs support the header X-HTTP-Method-Override and sending X-HTTP-Method-Override:PATCH via a POST will work. I tried that but got an Invalid Request back. Maybe Zoom doesn’t support that or maybe something else was wrong.
Anyone know a workaround for doing an update meeting when you can’t send and HTTP PATCH?
HTTP methods I can send are – DELETE GET HEAD POST PUT TRACE
Yeah, it’s lame that it doesn’t do Patch. I’ve researched it a bit and many over the last few have complained and entered an idea that it be added. Some speculate that it’s built on a Java library that doesn’t support patch and they haven’t gotten around to upgrading it. Bottom line is I’m stuck with it and have to work around it.
I know I can do a delete and than a create because I have all the info. I’m just wondering if there’s some kind of hook to work around it so I can do a patch . Like some services will handle that custom header I mentioned in my first post.
Yeah, I tried that. I got an unsupported method exception. FYI, SF has a work-around for their own REST API. They will recognize a parameter on the URL string and if that’s there, they will interpret a POST as a PATCH.
SF has something called an Idea Exchange where you can request features. It’s there and has a few hundred votes. (The Idea Exchange doesn’t work really well for development issues as there are probably 100-1000 end-users for each developer. That means developer-related issues aren’t going to get enough votes in comparison to user issues to get a lot of attention.)
And yeah, it is totally on the SF side. With REST services become the de facto industry standard, I’m hoping they get PATCH on the road map.
The workaround I’m in the process of coding is to do a delete and then a create. I have to do that since there is no way to send a PATCH I suspect it will work. We only have to send a handful of items in the create request and they are all at hand in this place in our code so it is easy to construct the new create request. We needed to do that same solution for another vendors library we call.
I coded a workaround of doing a delete and a create. That has a disadvantage of the meeting id may change. But I found it has one advantage. I adjusted the delete so if it returns a failure it ignores the failure and continues with the create. That will allow our reschedule function to work smoothly if the prior meeting has either inadvertently been deleted or started.
I suspect it will work. We only have to send a handful of items in the create request and they are all at hand in this place in our code so it is easy to construct the new create request. We needed to do that same solution for another vendors library we call.