At the moment, /projects and /notifications are both polled by the client which is not very efficient.

HTTP caching could alleviate the burden on the server by returning 304 if there is no new data since the last request.

The basic flow is this

1. The client makes the first request and the server checks the request for a header (if-none-match etc.) for an Etag or unique identifier. As none is given, the server generates a unique identifier and responds with an HTTP 200, the json for the resource and an Etag header with the unique identifier.

2. The client stores the Etag in memory or sessionStorage or somewhere from the response and includes it in the next request in a If-None-Match header.

3. The server recognises the if-none-match header and checks the value of the header with the current Etag for the requested resource and if they match, the server responds with an HTTP 304 and an empty response indicating that the client's cached copy is still valid.