If you are building a client capable of caching a local version of server data (perhaps to use it in offline mode), the need for a syncing mechanism becomes apparent. There needs to be a way for the server to tell the client when the data was last modified and then a way for the client to inform the server that it only needs the changed data.
To my knowledge there is no way to express this mechanism directly with RFC 2616, so lets take a look at how the big boys do it.
You can see that all APIs that support sync use a variation of the word since to pass along a timestamp parameter that tells the server which data to return, but they all use different mechanisms to report this
since parameter to the client.
You should never let the client send along it’s local timestamp as that might not be in sync with you server which will result in data loss. The obvious choice is for the server to send along the desired timestamp.
Instead of trying to change the JSON responses to include a since parameter, lets try and find something RFC 2616 already provides.
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified. – RFC 2616
Whenever a client makes a request to an endpoint, the server already returns a
Last-Modified header which indicates when the requested endpoint data was last changed. All the client needs to do is save this timestamp and send it along with the next request, url encoded.
The beauty of this approach is that syncing is an add-on to your API. If the clients knows how to handle syncing it has a very simple way of doing just that. All other clients can still use the same API witouth ever even knowing about the syncing mechanism.