I just recently got done helping prove out a very interesting concept that I thought I would share. This may not be anything new for some of you but for many this may be a very eye opening concept. It has to do with how you can combine three technologies to give you a very resilient and “push event” driven RESTful API for your applications and/or customers to use.

A technology many of us already know and love is Microsoft’s WebAPI framework that comes built into their ASP.NET MVC framework. It enables developers to very quickly build truly RESTful APIs that by default use JSON for the data messages. I have been using this platform ever since it was in pre-release and if you are in the process of evaluating your options for building an API – this is the one to look at. More information about it can be found at http://www.asp.net/web-api.

Now, this is only part of the picture and I have said nothing earth shattering so let's get on to the good stuff.

So lets say you or your organization/team has spent the time to build your API on the WebAPI platform and everything is going great but now you have come to the point where you need your services to talk to each other. Do the services call each other? Well that doesn't feel right. Plus, how do I  know when one of the services does something that another service needs to respond to as well? Do I use SQL data triggers? Ick!! Enter NServiceBus by Particular Software (http://particular.net/NServiceBus).
As it’s name implies, it is at its core a service bus that can be used to distribute events and messages between various listeners. It enables you to decouple your services to achieve a true SOA (service oriented architecture) but maintains a transactional consistency, reliability, and scalability you will need. This means your services can subscribe to events other services publish. Ok, a bit tough to follow so lets look at an example.

Say for simplicity sake you have two WebAPI services; a Inventory API and and a Products API. Now, lets say your Products API needs to know when the Inventory API changes available inventory so it can update the “availability” information on its products. This can be easily achieved by the Inventory API publishing a “InventoryUpdate” event to NServiceBus which then puts it in its queue and broadcasts the event to all subscribers of that event. For the ProductsAPI to get this event it simply subscribes to the “InventoryUpdate” event. Bam! You have “connected” your services together with NServiceBus.

So, thanks to NServiceBus your services are “talking” to each other via events but that is really only part of the picture. Wouldn’t it be nice if you could take those events and pass them on to the consumers of your APIs? But wait, we are talking about a WEB API so how can this be done? Enter SignalR.

Only until recently it was just wishful thinking of API builders to be able to push notifications to consumers of their APIs. Now, thanks to a new framework put out by Microsoft called ASP.NET SignalR these dreams have coming true. Essentially ASP.NET SignalR is a library that makes it incredibly simple to “push” events over the HTTP protocol. Without going into too much detail, SignalR uses HTTP web sockets to push in real time data to a website. More information about the framework and how to use it can be found at http://signalr.net/.

So how does this apply to WebAPI you ask?

Well, since your WebAPI is really just a website it can use SignalR to push events to your API consumers so they get real time notifications. In the past your API consumers would need some kind of “heartbeat” that constantly called your API for status updates to determine if an event occurred but with SignalR they will be notified immediately via “events” your API pushes out. Whether the consumer of your API is another website or application it can attach event handlers to these push notifications – essentially closing the loop on service events.

While all of this may seem very confusing and complicated, for what is being achieved it is actually very simple and elegant. This approach allows you to develop a very distributed API while maintaining interconnectivity between each of your services and their consumers. I can almost guarantee you we are going to see more and more need for this type workflow and with WebAPI, NServiceBus, and SignalR, there is no reason you can’t do it now.

Feel free to leave me comments or feedback. If you have specific questions about this post please contact me at matt@yosttechnologies.com or go to our website at http://www.yosttechnologies.com and submit your comments.