Webhooks is a brilliant way to stay updated on things happen around a service. Many services and products running on cloud allow developers and other interested parties to listen to the responses sent via HTTP Post. Its like a subscription for a newsletter and they sends whenever there is a new edition.
We need four sources of information in order to create a webhook.
- Resource url - The list or site url that you will be subscribed to.
- Subscriber url - The url where the HTTP Post request will be received by.
- Expiration date - By default, a webhook expires in 6 months after it is created and that is the maximum, you can make lower if needed.
- Client state - This is a non mandatory text you can include if necessary for the validation processes and any other at the receiver end.
Validating the request
The server sends a request to the client at the point of webhook creation in order to validate the receiver. The webhook only gets created/ activated if the webhook received a success message.
If you look at another service like Jira, they send much dynamic information on the webhook response. It can be good as well as bad at times. SharePoint has simplified its response with the IDs being the highlight.
A sample response is as follows.
Another good thing with SharePoint webhooks is it groups the notifications to a single response. Many other services (eg: Jira, Confluence) send one in every change happen so sometimes if you are using a single endpoint, there are chances of failures at the endpoint.
Best Practice of Use
Now you might have dreamt of doing so much bigger things when a webhook request is received. But keep in mind that you are doing it in a web request. So the chances are that IIS is timing out if it exceeds 90 seconds by default. What I would recommend is storing all these responses in a single database before doing anything. That way you can pick it up if some process components are lost in the expected action.
So, enjoy your webhooks.