Managing Alerts in Web Application Using RESTful API

Question

I have designed a RESTful API and I am now working on creating a web application to use the service.

One thing I am struggling with is how to manage alerts in the web application (similar to the alerts stackoverflow gives in your profile for a new answer, response etc).

Basically the web application is a workflow between a user and his clients. Certain tasks have to be completed in order, and the web application alerts both the user and his clients of any actions. The user also gets alerted to any client actions that are outstanding.

The way I have my architecture setup at the moment is that the API has no knowledge of alerts. It simply stores the resources that are retrieved by the web application. To work out if an alert needs to be displayed, the web application looks at all the resources, and based on a set of rules, decides what alerts need to be displayed.

The problem I have is that I'm not sure this is a very efficient way to do things. There are a number of different alerts that can be displayed, and they depend on different API resources which will all need to be retrieved when a user or client logs in.

My question: Is this the best way to achieve what I want, or are there other methods which are better to use and will help decrease web application load time and api calls?

Answer 1

So one thing you could do is to make the checking of rules asynchronous. Once the resource is created (maybe as an aspect) you put a reference to the posting in Rabbit MQ, Active MQ or even a database table that's periodically swept by another process. Using aspects means your API need not know anything about alerts. (Although you should be careful about what verbs you use with these side effects - i.e. POST is your friend but GET would be inappropriate).

Can you be a little more specific? Maybe disclose the frameworks or language? There might be a more better way to do this than AOP.

Answer 2

You are the best person to answer your own question.

Are alerts integral part of the system? Let's say tomorrow you write a mobile app that interacts with your server. Is it reasonable to assume that it will need alerts too? Or are alerts specific to the web site use case? If the answer to the first question is yes, then you probably want to have the server handle alerts. This way when you get to write your moobile app, you don't need to replicate the alerts code you wrote for the web site. But if alerts are specific to the web site use case, you can and should leave the logic in the web site in order to keep the server's api clean and focused.