Allow webhooks that support GET

[rohankapoorcom]

Description:

Copying the description from my comment #15376 (comment):

I'm just starting migrating over the Prometheus component to an auto-generated webhook url and noticed that it (and several others) are using GET requests to scrape data from Home Assistant instead of POSTing data to Home Assistant. I'm going to extend the webhook component to support GET requests as well first.

Related issue (if applicable): relates to #15376

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[rohankapoorcom]

I'm not sure if the best approach is to allow each webhook to be used as GET/POST endpoint. I was considering another approach: changing the webhook schema to include an HTTP method in addition to the webhook_id but I think that unnecessarily over-complicates things and this is sufficient.

Thoughts?

[balloob]

Webhooks are not for returning data. If a component wants to expose an endpoint that returns data, they need to define a webview.

[rohankapoorcom]

@balloob in light of your latest comments on #15376 and #17804, I wanted to bring this one up again.

Here's my reasoning for wanting GET based webhooks:

• There are some services example that allow GET requests to be used to send data. I would hazard a guess that there are likely some services that only allow GET requests to be used for webhooks (but I have not looked for them).
• Similar to the discussion we had in Migrate dialogflow over to the new webhook component #17804, we have several components that provide data out to external services when their endpoints are hit (example). That behavior (sending a response) is not quite that of a traditional webhook, but is a scenario where it's still helpful to have a common url prefix (for whitelisting) like /api/webhook/* and avoiding the security implications of trusting third parties with a global long lived access token (when all they need is access to one specific url).

Again, I think we could solve this use case without using the webhook component (if we want to keep that component only for POST requests, by creating a new generalized component (similar to the webhook component) to be used for all these things that need an authenticated webview (but only for GET requests).

Personally, I think it's a better solution to allow this case to be handled by the webhook component itself, rather than having two similar components (with slightly similar url schemes) and possible confusion for other developers down the line.

Let me know what you think and how you want to move forward.

[balloob]

customer.io uses form encoded, so is POST ?

[balloob]

Webhooks should focus on getting data in, I don't want to increase the scope about getting data out just now.

[rohankapoorcom]

Okay, sounds good. Let's work on getting all of the inbound webhooks migrated over to the new component and then we can circle back on the things that are using HomeAssistantViews to get data out.