Does it matter if you trigger a Make webhook with a HTTP module with a POST, GET, or PUT method?

Does it matter if you trigger a Make webhook with a HTTP module with a POST, GET, or PUT method?

I’m using the HTTP module in various scenarios to call my Make webhook scenarios and the webhooks don’t seem to behave any differently with either method.

If it doesn’t matter then, I would just use GET for everything as it is supposed to be faster (which http method is fastest - Google-søk)

1 Like

Webhooks usually work with a POST but make probably does ok with a GET even though GETs normally don’t have a http body content.

I would not use put at all. No reason to.

Thanks for your reply. Since I’m only using query parameters and don’t use body content, I think I’ll just use GET for everything and see what happens.

It would, however, be interesting to know if GET is indeed faster. There must be some way to create a scenario that iterates through several HTTP requests and time how long it takes to complete using either GET or POST.

Of course. Use an iterator with a numeric counter and then record the timing in a datastore. You can benchmark the time it takes to iterate 1000 calls or so if you have the operations to burn.

My guess: GET will be faster but not significantly so. And really why would it matter the speed anyways? Make execution speed is already pretty fast.

Speed matters when a webhook scenario is being used as a form handler, and it needs to complete before redirecting to a webpage that may vary depending on the contents of the form submitted.

This is compounded when a webhook scenario makes calls to other webhook scenarios which is something I do to reduce duplication and make code easier to manage when there are procedures that are used frequently.

I don’t have the spare operations right now. Hopefully, someone else does and will post the results to this thread.

The implementation needs to be split between the form handler scenario and the rest of the scenario logic. You can’t do all the logic in one scenario and then redirect at the end and expect any performance. The webhook is the least of the bottleneck. Your form handler scenario needs to spawn off to another scenario via webhook and let that run asynchronously.

I think I follow you, but I’m not sure how to make the spawned scenario run asynchronously.

Here is an example of one of my form handlers:

The scenario calls 3 webhooks which are numbered 10, 23, and 65. These 3 are not required to complete in order to construct the redirect URL in the 302 response. However, the way the form handler currently executes, it waits for a 200 response from each spawned scenario before continuing it’s execution.

Here is the spawned scenario “10 Add Tags”:

How do I make the form handler scenario not wait for a 200 response from the 10 Add Tags scenario?

Spawn off from your main scenario more aggressively so you don’t have anything blocking. And the 10 tags scenario should not need to return a response.

All your scenarios you spawn should be able to return instantly. You should handle any errors with error handlers rather than returning a 200.

Webhooks by default are sequentially processed too.