The point is that generating the collection is more expensive than returning the ETag, if it's cached (and it is, with NodeBB).

So if I wanted to check the context for updates, I could issue a lightweight HEAD instead of a GET, and the target server could simply bounce back the ETag.

Likewise, I think it sends the appropriate http response (304 Not Modified) when If-None-Match matches the ETag, or something. So I think with collections of object ids, the savings are minimal but it could add up to much more for endpoints that return entire objects... Like an outbox!

It's been awhile since I worked on that code.

If the server wants to say, "this content is different for different users", you use the Vary header. For OAuth, you'd use Vary: Authorization, say. And the cache knows to separate data for different users. Same OAuth token, you can reuse the cached data.

We include our ID in the Signature (or Signature-Input) header. But we also include a timestamp there, so every single request has a different signature (by design).

If there were net items added or deleted, `totalItems` will be different.

If the same number of items were added and deleted, the most recent item will be different.

So you can check synch with a couple of hits.

None of them... yet...