Generic Webhook is too limiting to be useful/differentiated from HTTP trigger

[timheuer]

In investigating working with Functions with other providers, I've come across a few scenarios where the API provider has a webhook strategy that is both a GET/POST implementation (GET issues a challenge first, then upon successful challenge, they POST the data). In doing this I chose initially to use the generic webhook trigger, but realized this wasn't going to work as this is a POST-only policy and validates application/json.

This seems like an arbitrary limitation. Webhooks in the industry don't define that it is a POST-only world, yet we are defining that in a policy-driven way with something called 'generic webhook' which seems wrong. When faced with these, this appears the recommendation is to use HTTP trigger anyway in these scenarios, thus not making the great case for Generic Webhook to exist.

Recommendation: let's remove (or fix) the Generic Webhook pattern here to be more flexible or remove it and go all-in on HTTP trigger being the way to interact with webhooks in the wild.

[christopheranderson]

@jeffhollan or @alexkarcher-msft, one of you wanna take this feedback? Also, /cc @fabiocav

[alexkarcher-msft]

I'm not quite sure I understand your issue. When I create a generic webhook function it's configured to accept all HTTP verbs, and I can throw GET and POST requests at it just fine. You can even define two functions at the same URL and have one respond to only the GET requests, and the other only respond to the POST requests.

Can you provide some more info on what errors you're seeing back from your function?

[christopheranderson]

What's the difference between Generic WebHook and HTTP, then? What's the point?

[paulbatum]

Moving this to unknown milestone while discussion happens. Please ping me when this issue is actionable.