As it should be. The question is: can you use HTTP to transport event notifications? Actually, can you use TCP to transport event notifications? Yes, you can

As it should be. The question is: can you use HTTP to transport event notifications? Actually, can you use TCP to transport event notifications? Yes, you can, but it's a bit unwieldy because you need some sort of keepalive / heartbeat with which to distinguish inactivity from transient network problems (and then attempt to reconnect). Then again, even if you were using UDP you'd have to do some sort of keepalive / heartbeat. I use an HTTP server that supports "tail -f" via chunked transfer-encoding responses to indeterminate byte range requests (Range: bytes=${offset}-) that don't end until the file is removed, renamed away, or replaced (renamed over). This server also supports weak ETags constructed from (device ID, inode number, generation number), If-Match, and If-None-Match. This allows clients to GET a resource whose body is the event stream and hang in there waiting for events. Again, you need to add a heartbeat in the event stream as HTTP chunked transfer-encoding does not have this, and you need to detect network problems. But otherwise this works fantastically well and it is HTTP and RESTful.