HTTP (HyperText Transfer Protocol) has become a widely used standard protocol for communications between a server and a client.
Want to check your email? You (client) navigating to the email site will prompt an HTTP request to the server and return the emails you have in your inbox.
Want to buy new protein bars? You searching for ‘protein bars’ online will also prompt an HTTP request to the server and return your back results for ‘protein bars’. This happens basically everywhere on the web. However, have you ever thought about the magic that happens when you pay using a third-party website (perhaps Stripe), and you receive an email from the company that sells your protein bars with your invoice right after payment? That’s most likely due to a webhook event.
Webhook Event and HTTP Requests
HTTP requests are fun and all. However, how can you expect real-time event updates like the email of your purchase invoice with a simple server query? One way would be to constantly make requests to see if the update is available or not. Another (better way) is by utilizing webhooks.
Webhooks are nothing but simply an open endpoint on a server that accepts HTTP requests. Upon receiving this request, the server acts on it. For example, you pushing that purchase button on the portal creates an event that tells the original seller about your payment. This event is communicated to the original seller in the form of an HTTP request. The original seller would have an open endpoint (webhook) that will accept this request and send you an email with the invoice for your purchase.
In a way, you could then say all webhook events are HTTP requests but not all HTTP requests are webhook events.
Why use Webhooks?
The question then remains, why do we not just keep asking the server if the payment is complete or not? Theoretically, nothing is “wrong” with constantly asking (keep making HTTP requests) if the payment is done or not (this is called polling). However, this method of requests is incredibly wasteful in terms of resources and quite often undesired.
It is almost like instead of waiting for your waiter/waitress to bring you your food at a restaurant, you go up to the waiter/waitress and constantly ask if the food is done or not. What if you ordered a 7-course meal? You would have to constantly ask about 7 different items. It is a tad bit overkill. Why not just sit down and wait for your food?
Be resourceful
In the end, the decision to either use simple HTTP requests, webhooks, or other communication methods in your server comes down to you. Making use of different methods for different use cases can help you keep your service fast and efficient.
If you are expecting data but do not know when it will become available, try to use a webhook implementation. If you want to know something right away to display to your customers, make an HTTP request to the server.
