I am designing a REST API for my mobile clients to interact with our app server (built with Django/django-rest-framework if it makes any difference).
There are a number of different objects accessible through the API, some changing frequently (say daily), some almost never changing (on average less than once per month), and some for which only some nested records will be changing (think a blog post for which we add new comments a few times a day).
Because the clients are sensitive to data transfer volume (for cost reasons, mobile data in developing country), I want to limit this, especially when they download a list of object (eg: the list of blog posts objects mentioned earlier). Data transfer is by far my biggest concern here, long before server-side load.
I have thought of using something similar to the HTTP If-Modified-Since
header (https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.25), that could work on individual object requests, like GET /api/blogposts/<id>/
. But with high network latency (ping times of over 500ms are common), running dozens or hundreds of requests seems like a bad idea.
To obtain a collection of records, I would expect the following behaviour to help more in my case (the requests I'm talking about are similar to what is described in this answer: taylored collections per user)
GET /api/myblogposts/
would initially return a JSON list of objects, not just the IDs:
[
'post1': {...},
'post2': {...},
...
'postN': {...}
]
Then a subsequent GET on the same url with appropriate header If-Modified-Since: Sat, 29 Oct 2016 19:43:31 GMT
would filter the list to return only records modified since then. The client can then merge the changes into its local data store.
Does this strategy seem to make sense? Is there some existing standard for client and server to negotiate what subset of records to transfer?