Difference Between ASP.NET WebHooks and Web Services?

Question

I have been following Henrik F Nielsen's impressive series of blog posts on the new ASP.NET WebHooks technology. The latest post which can be found here, if interested.

In another, earlier one of these posts, I asked in a comment what the difference is between WebHooks and SignalR. An answer was later posted to a link to a great question (and answer) here on StackOverflow.

However, now after reading the answer(s) to that question, I have to now ask: What is the difference between using ASP.NET WebHooks and using a regular ol' web service? The accepted answer given in the SignalR comparison answer suggests to "Think B2B communication". However, when I think B2B communication, I immediately think of web services -- either SOAP or REST (which -- as I understand to this point -- uses HTTP verbs much like WebHooks).

I have been interested in learning WebHooks, and have been following along with these posts, but confusion remains on how all of this fits together, especially when it seems other technologies basically do the same thing. It would be great to get clarification between the two technologies.

Answer 1

It's just a layer on top of that "plain old mvc" stack that deals "automatically" with specific saas services.

Once Upon a Time -- Webhooks were coded Manually

Think about coding a listener for a dropBox webhook. You have to code all of the parameters and validation from scratch, you have to know oauth2.0 (and figure out how to activate it), and you need to figure out which hooks are available.

Webhooks in asp.net let the guys who coded Dropbox ALSO code the parameters and skeleton code for your webhook. So it's easier to get it right quickly.

Obviously, if you're publishing your own webhooks, then they are providing the plumbing so that you can create "observers" within your code, and they provide an automated way for others to subscribe to those listeners. Again, you could code that all yourself, but following standards is an easy way to make sure others don't have a steep learning curve when it comes time to consume YOUR hooks.

Think "nuget for web services"

Think about how nuget fundamentally changed the process for adding references to your code. You just add packages to your solution, and the system takes care of downloading, web.config changes, etc.

This service does the same thing for saas web services. Now, as a saas service provider, we can code a little nuget-like package to download/install listeners. No more kb articles explaining how oauth1 vs oauth2 vs api-keys work. We just create a little install wizard and off you go!

And yet, when we first started out with nuget, there were a subset of coders asking "what's the difference between nuget and just adding references to your code manually."

vs SignalR

SignalR is a live "active" connection to your server. It's creating your own chat-like service. Webhooks (the generic concept) are just an http(s) call to one of your end points. That, I think, was the point of the answer to your other stack post.

Webhook the concept vs MSFT "WebHook"

Msft is taking that https post one step further and saying that Dropbox (or ANY webhook provider) can create a wizard for other to use that steps them through authentication, query parameters, etc. it's a cool idea because you won't need to read the Dropbox docs to consume a Dropbox webhook.