I did a bit more reading about this. I found this relevant stack overflow post.
It seems like there are a few approaches, but generally speaking record a last-modified timestamp and send this in an API response header, so clients only download data when new stuff has been added. I guess the API could also have a feature to only send back the new stuff when a last-modified timestamp is part of the request.
Worth considering these types of features imo when building APIs that are intended to be used in jamstack environments.
@patarapolw
theoretically if the API supports proper HTTP caching it would work, the problem is that most generic HTTP libraries do not respect caching headers by default so it's a non starter :D
Yeah I was thinking that a hash of the content would be the easiest way to identify changes quickly, but how would APIs present this data?
Feels like a kind of complicated thing to implement, like file sync but for API data.
I did a bit more reading about this. I found this relevant stack overflow post.
It seems like there are a few approaches, but generally speaking record a last-modified timestamp and send this in an API response header, so clients only download data when new stuff has been added. I guess the API could also have a feature to only send back the new stuff when a last-modified timestamp is part of the request.
Worth considering these types of features imo when building APIs that are intended to be used in jamstack environments.
@patarapolw theoretically if the API supports proper HTTP caching it would work, the problem is that most generic HTTP libraries do not respect caching headers by default so it's a non starter :D
Not if you are building your own client :)
There is such a massive gain in terms of optimisation that it would become worthwhile quite quickly.