If the list is small and changed frequently, it may be the best to let the subscriber query the full list from time to time. However, if the list is huge and changes occur seldom, you could log any change to the list as a sequence of INSERT/UPDATE/DELETE commands on the server into some kind of
commands table. Each command needs a sequence number, in increasing order, and the subscriber should remember which commands were already processed in the local cache. Then, when a subscriber gets a notification that the list "LID" has changed, he sends a query like
SELECT * FROM commands
WHERE listid= :LID AND sequenceNumber>:lastSequenceNumber
ORDER BY sequenceNumber
to the server and retrieves only the change commands since the former query of that type. Then he processes the commands to the local cache of the list and increases "lastSequenceNumber" accordingly.
Note this will also work when a subscriber misses a notification or with no notifications at all. The subscribers can just do the command querying and processing in regular time intervals, this will still work. The notifications are only for keeping the latency and the required number of roundtrips low.
If you go this route, you will also need a strategy for starting new subscribers to an existing list, with an empty local cache. For this case, the whole list should be transferred to the subscriber once, together with the last sequence number of the final command which was already applied to the list.
If you google for "Command pattern" or "CQRS" or "event sourcing", you will find more information about this strategies.