How much difference in application performance or server overhead is having one network call rather than two per update going to make? Well, it depends on how many simultaneous clients you expect, and how often they'll be polling for updates. If you have a "small number of clients" like 10 or 50, and they request updates every N seconds (say N between 10 and 120), you can do the math and find it's not a substantial network or server load, so you'd probably be wasting your time optimizing it.
On the other hand, if you had 100s, 1Ks, or 1Ms of simultaneous clients, and/or they're requesting updates every second or few seconds, and/or you have not just two kinds of objects to communicate but M>2, by all means do everything possible to optimize the interactions.
This still leaves open a key question: Is adding new mega-REST endpoint (/sync
) really the best way to do that?
Maybe not. Cormac Mulhall outlined some of the downsides. A more subtle problem is that sync is fundamentally hard. It seems not so difficult, but a lot of shops have repeatedly broken their picks on it.
Why is sync hard? Well, let's just scratch that surface. You mention URLs specifying ?since=<last-sync-timestamp>
. Is that the server's timestamp, or the client's? They will be different. Distributed timekeeping is itself hard. Clocks vary. You can help this along by adding another rest call /time
that helps the client estimate how far its clock is off the server's clock. But now you've got the complexity of time drift estimation, just like inside Network Time Protocol. REST isn't so simple any more. And just what does a timestamp mean, anyway? ?since=1418070480
means...? Is it the start of that second, or the end? Keep in mind that CPUs can execute ~10**11 instructions per second. Seconds are a crude metric. So you say: "You know what? There's going to be error, so I'll just put in a margin for error." You coordinate clocks as best you can, then add another 20 or 30 or 60 seconds back, just to catch stragglers. Now you've think you've got the "accidentally missing updates" problem licked--you haven't really, in a system of any complexity, but let's just pretend. But you've created another problem: The possibility of duplication, because you're asking for another N seconds of data before where you really think you need it. You'll have to build client-side code to make sure objects aren't double-posted. REST was supposed to be simple!
Even with all this, you haven't addressed the elephant in the room: You still have a polling-style update, where the clients have to constantly ask, ask, and re-ask: "Anything new? No? Okay. How about now? No? Okay. How about now? No? Okay...." Your server is still getting hit with needless requests. 90+% of which will always answer "Nothing new to report."
The truth is, you do not yet have a communication style that is even half-way suited to synchronization requirements. Polling is always going to be a chatty, server-loading technique. What you really need aren't AJAX or AJAJ update polls, but at a minimum Comet (long-polling reverse AJAX calls)--or even better, a full back-and-forth communication mechanism such as WebSockets. These allow your server-side code to establish push techniques or push-pull interactions that, while not automagically fixing all of the semantic difficulties of synchronization in a distributed world, substantially reduce the network call, server overhead, and code complexity required to have truly synchronized endpoints.
In summary, one mega endpoint rather than two individual ones is a minor issue. If you want efficient temporal synchronization, the real issue is you need a better interaction mechanism.