Here is mine:
Webhooks allows one web app to share real-time data to any other web app
Comment out more about webhooks
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Types: char and boolean
Ricardo Caselati -
Introduction to Git: A Powerful Version Control System
pawan deore -
Static Keyword in C# Explained in 1 Minute
DotNet Full Stack Dev -
Accessible, sustainable, and creative web development
Ingo Steinke, web developer -
Top comments (9)
I personally don't trust web hook callbacks..
If they check that response was successful then sure..
But i have been always afraid that if webhook callback is sent and application triggers error and data is not synchronized.. what next?
I would better build it in on my application side to send request to third party application to get data.. not wait for callback from them..
I do not trust anything, even my own code. The point of webhooks is to allow immediate notifications between different parties. That's a requirement of nowadays where everything should happened very fast, almost instantly. Sending some regular request to the 3rd party from your application should be as a fallback solution, to make sure that the data is in sync in case something went wrong with the webhooks. Though, in 99.9% of cases it all we be fine with webhooks.
Error handling depends very much on the implementation (on both sides). HTTP allows for very robust error-handling, and a web-hook can choose to try again or send a notification to an administrator when message delivery fails, and the callee can communicate what went wrong and whether the caller should try again.
Nice insight. I think both should be available. There is a case to be made for both depending on the data/task.
Stripe is the perfect example for making sure your webhooks are secure and filled with contingencies (helping you test error handling).
Nowadays I can't imagine integration with some 3rd parties without webhooks. For instance payment processing. After successful payment you cannot rely on the client in order to confirm the successful payment. Waiting for some regular cron job which can run even every minute to confirm the payment status on the server side is OK and should be in place as a fallback option, but it is way too slow. So webhooks is a "must" for communication between different parties in order to notify each other about any events.
Webhooks are an amazing implementation.
As Arthurs says, they can fail (how many times have we seen Travis not triggered because the GitHub webhooks were out of order?), but they are extremely efficient.
Implementing on your own server is easy, and separating them into another service ensures performance on both sides.
On the receiving side, if your application is fault tolerant there should be no problem. A bad response should trigger a specific HTTP status code that will prompt the sender to stop and maybe notify their user (403 for example), and if you don't get an event, then there's nothing you can do, so no specific management there.
Every modern app should have some sort of webhook implmentation, whether receiving (GitHub, Zapier, Stripe...) or sender (Zapier, IFTTT, other business integrations).
They're just REST API calls, so yea, I guess they make sense. There's certainly situations where a more specialized tech like MQTT would be a better choice, but for many applications it's just more user-friendly to deliver your data via REST.
That's a really brief explanation LoL