I have a RESTful API with corresponding clients.

If a client request fetches a set of resources (Events) based on a filter, say events taking place between 2015-04-13 - 2015-04-19. If an event which has previously been synced to the client changes time on the server so that it will be outside of the above time range it, the next request will not include the updated event and the client will not know about the change until it makes a request which includes the updated time.

The solutions I'm thinking of are

  1. Adding simplistic version management by creating a new events with the updated time which refers to the original event whenever an event is updated. When a request is made the server would have to return the latest version of all the events within the time range.
  2. Adding a new resource (say EventUpdate) which only tracks time changes of an event leaving sort of a "gravestone" where the Event used to be. Whenever a request is made EventUpdates would have to be checked to see if there previously was an event in the requested time range, if so, these Events should also be included in the response.

Right now I'm leaning towards solution 2. since it seems less overkill for what I need right now.

Is there any standard way of solving this kind of synchronization problem?

  • I am having a hard time thinking of a "concrete" example for you problem. Can you maybe give a specific example? Otherwise, my answer would be, why would an update outside the requested range have any affect on the results. You asked for events in a specific range and you get them. Anything that happens outside the range doesn't affect what happened inside the range. – Dunk Apr 17 '15 at 16:01
  • well, moving an event from inside the range to outside of the range will affect the response. I suppose I could just before receiving the response on the client delete all events that are in range and replace them with the new ones – Erik Johansson Apr 20 '15 at 20:56
  • 1
    If the events, date range and subsequent request are closely tied, why should not remove the event when it goes out of interested range? – Saran May 13 '16 at 5:26

Is there any standard way of solving this kind of synchronization problem?

I believe not, but I can propose a system redesign.

Make two API methods instead of one:

  1. Method returning event ids for events currently scheduled for the specified date interval
  2. Method returning event details together with updated_at timestamp for a given event ids

If a client wants to check or recheck the specified time range, he uses method #1. If he wants to fetch event details, he uses method #2. #2 will return an event by id even if it has shifted its date.

To minimize traffic for method #2 you can use scheme used by HTTP protocol (If-Modified-Since header).

To make a sync on a client, you can make one by one API calls first to recheck specified interval and then to update all events (those you have ids from the previous calls and those, which were returned by method #1 as new).

Does that solve your case?

  • Yes it would solve my problem, I'm just worried that it's a bit heavy handed to recheck all events within the range. Thanks for the suggestion! – Erik Johansson Apr 20 '15 at 20:52
  • Do you see anything inherently wrong with the solution I suggest (option 2 that is)? – Erik Johansson Apr 20 '15 at 21:00
  • @ErikJohansson No it is ok. It's just that it introduces a new entity into the system. Which might complicate matters depending on how you will work with those. They might require separate caching, internal architecture etc. – Vladislav Rastrusny Apr 21 '15 at 8:02
  • I agree. Now I'm thinking that maybe it would be best to keep an complete copy of all events on the client and never ask for particular changes but just updates with If-Modified-Since header – Erik Johansson Apr 21 '15 at 20:17
  • 1
    This is the "right way". Importantly, it avoids information automatically disappearing out from under the user. – Solomonoff's Secret May 8 '17 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.