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's just right to open websocket connections for both. But then I have to re-write all 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 I could let these users use REST and websockets only when there are more than 1 participant? This requires additional checks and complexity, not sure if it's worth it though. As you see I'm a bit confused.

Should I just rewrite everything to use websockets? Or does a possible mix of REST/websockets and/or other technology make sense?

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?

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's just right to open websocket connections for both. But then I have to re-write all 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 I could let these users use REST and websockets only when there are more than 1 participant? This requires additional checks and complexity, not sure if it's worth it though. As you see I'm a bit confused.

Should I just rewrite everything to use websockets? Or does a possible mix of REST/websockets and/or other technology make sense? Thanks.

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's just right to open websocket connections for both. But then I have to re-write all 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 I could let these users use REST and websockets only when there are more than 1 participant? This requires additional checks and complexity, not sure if it's worth it though. As you see I'm a bit confused.

Should I just rewrite everything to use websockets? Or does a possible mix of REST/websockets and/or other technology make sense?