I am working on a multi client/single server app. Communication between the two happens via RESTful API. There are several resources that need to stay in sync across all clients, including images captured from camera, likes and comments on these images, user profiles and user followers/followings. My current approach involves GETing all resources changed on server since last sync, like GET /images?since=<last-sync-timestamp>, GET /users/:id/followers?since=<last-sync-timestamp> etc. and POSTing all client changes since last sync to the same endpoints, like POST /images, POST /user/:id/followers
The main drawback to this approach is way too many network calls – For each resource I need to sync, I need to perform at least 2 network calls.
So I am thinking about introducing a new endpoint like /sync which provides all syncable resources that have changed since last sync timestamp. Both client and server will need to parse the JSON and put the respective data in appropriate tables, but now, no matter how many resources I have to sync, I will only need to perform two network calls, but change the structure of the JSON as reosurces get added/removed.
Any thoughts on why the second approach is superior/inferior to the first one?
Best Answer
In REST, you should think of URIs as identifying an addressable resource. So as long as you think of a "sync" as a noun ;) you can define that resource in whatever manner suits your requirements.
At surface level, in REST we talk about collection resources (like the collection of users) and individual resources (like a single user), so a resource that is an aggregate of other resources is in keeping with that.
The idea of "a resource" is extremely broad. I don't know that there's a precise definition. So an aggregate resource that bundles up the smaller resources saves bandwidth and reduces latency sounds like a good idea.