Menu
Best I could find was this wiki entry
I I thought "surely there must be more to it than this".
Am I missing something?
566
Webhooks typically are used to connect two different applications. When an event happens on the trigger application, it serializes data about that event and sends it to a webhook URL from the action application—the one you want to do something based on the data from the first application.
Webhooks are an incredibly useful and a resource-light way to implement event reactions. They're an essential tool in any app's arsenal because they deliver data from one app to another, either by sending automated messages or receiving real-time updates about what's happening inside your software environments.
Some real-world examples of webhooks include: Automatically receive an email every morning about your first meeting in case you forget to check your calendar. Have Instagram photos upload automatically to Twitter accounts. Configure the doorbell to flash the lights when it rings.
Working with webhooks exposes an HTTP endpoint that can be called from any actor on your server. Without appropriate measures, this could be extremely unsafe. However, there are now well-understood strategies that ensure your webhook endpoints are secured.
From the doc:
What is WebHook?
The concept of a WebHook is simple. A WebHook is an HTTP callback: an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST.
A web application implementing WebHooks will POST a message to a URL when certain things happen. When a web application enables users to register their own URLs, the users can then extend, customize, and integrate that application with their own custom extensions or even with other applications around the web. For the user, WebHooks are a way to receive valuable information when it happens, rather than continually polling for that data and receiving nothing valuable most of the time. WebHooks have enormous potential and are limited only by your imagination! (No, it can't wash the dishes. Yet.)
Why should I care?
As integrated as we perceive the web, most web applications today operate in silos. With the rise of API's we've seen mashups and some degree of integration between applications. However, we have not seen the vision of the programmable web: a web where you as the user can "pipe" data between apps much like the Unix command line. Some say RSS is the answer. They are wrong. The heart is in the right place, but the implementation is wrong. RSS is still useful, but it is not going to bring us the true programmable web.
We just need a simple way to get data out in real-time to let the user easily do whatever >they wantwith it. That means no polling, no content constraints, and no XML parsing. That means no RSS. Using HTTP is simpler and easier to use. PHP is a very popular and accessible programming environment, so it's likely to be used often for writing hooklets... getting data from a web POST in PHP is as simple as $_POST['something']. And making the request to the user script is as simple as making an HTTP request, something already built-in to most programming environments. In fact, web hooks are easier to implement than an API.
166
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
