I have a REST API that implements server-side pagination returning the following data:
{
items: [
{
id: 1,
name: 1
},
{
id: 2,
name: 2
}
],
nextToken: <some-hash-key> // cursor-based
}
How should the client application refresh the list if the resource gets updated (client isn't aware of the update, so this is a pull model)? I have some ideas:
Both approaches are fundamentally the same idea. The first approach is more costly but allows more real-time updates. The second approach is based on session ID which I think is more idiomatic, but no real-time updates. Is there any other approach?
REST APIs are not designed for real time updates; for that you need sockets.
It is not scalable to update every single update to client-side in realtime, so it has to be an updation at regular interval. The duration/interval time could be decided based on facts on the table.
You can use simple integration like https://socket.io and a cron like architecture to broadcast updates in regular intervals.
Version your list, send If-None-Match request headers with GET requests each n secs, or probably mins. Respond with 304 if not modified. Respond with new data if modified. Though this won't scale well. Using websockets and sending an update event scales a lot better. As of sessions REST is stateless, so you don't have those.