Using websockets for server “broadcasting”?

Question

I want to make it possible to edit shared todo lists in real time.

There's already a REST interface, and it's possible to send updates to the server - add items, mark items as done, etc.

For the client to get these updates immediately, I did some research, and it seems that the best approach would be websockets, as they are quick and reliable. Push notifications on the other side can take "a few seconds" and are not reliable. I think I also saw something about "HTTP broadcasting" which did look more suitable for videos and things like that. Can't find it again.

So I was wondering, first, if websockets are really the best fit for this, second, if it's a good practice to use this in combination with REST - that is, I do the "push" from client A to server using a REST call, and then do the "push" from the server to client B using a websocket. Of course client B can also send updates to the server which have to be pushed to A (and other possible participants). So maybe it would be simpler to open websocket connections for both and throw out my REST code. On the other side a list can also have only 1 participant (the current user), in which case a websocket is not necessary, so maybe I could let these users use REST and switch to websockets only when there are more than 1 participants?

Does a mix of REST/websockets make sense for this application? Or should I stick to one or the other?

Answer 1

You could use all 3. Use the REST API for posting information to the server, websockets for immediate updates, and fall back to push notifications to the end user if the app isn't running (and the user wasn't notified over the websocket connection).

Of course, the REST API isn't strictly needed since you can perform the same server-side actions using websockets that you could with the REST API. But whether that makes sense or not really depends on your server piece. Since you already have the REST API, there's no major urgency for you to rewrite it for websockets. But you can certainly start migrating the functionality to use websockets with the goal of eventually removing the use of the REST API.

Answer 2

If you want a complete WebSocket solution (there's no real need for REST unless you already have some REST framework on the server-side), there's an implementation of the shared todo canonical demo ToDoMVC by one of the Kaazing engineers that uses pub/sub with WebSocket. Its written in Angular and uses a universal messaging API.

http://kaazing.org/demos/todomvc/todo