4 ms·

> No, you use the query in querystring. Ok, but doing that straight on top of HTTP, will only cache queries that are exactly equal to previous ones. Not querie

> No, you use the query in querystring. Ok, but doing that straight on top of HTTP, will only cache queries that are exactly equal to previous ones. Not queries that are a subset of previous queries.

pbhjpbhj 11y ago
If the [data returned following a] query is a subset [of data points already returned] why do you need to get it again; if you actually need to re-retrieve it then it being cached is no use unless you dumped it from local cache mistakenly - that shouldn't be an often enough occurrence to need to cache the data. Or did I miss something?
- thomasahle 11y ago
  I'm thinking about the case where you have a cache between you and the server, shared by multiple users. I imagine this is useful at facebook, for example for loading parts of public peoples pages, etc. You are right, that if the data is only used by you, you can just have an advanced cache in the client, sorting it out for you.
jerf 11y ago
I think you have to be careful not to be too cavalier with the word "cache" there. While REST is sort of vaguely concerned with the ability to cache in the general sense, in real life we have to be specific about what is doing the caching. This is the sort of dynamic query you'd normally tell intervening proxies not to cache anyhow, so now we can reduce our concerns to the client and the server specifically. On the client, if it asked for a big chunk of the graph and now need to operate on a smaller on, I'd suggest that if the client does not want to incur another round trip, it would be incumbent on the client not to ask another question. (This is further backed up by a consistency concern; if I ask again, I may get a different answer because it has actually changed in the meantime. You may be better off with your code not even looking at the changes.) On the server, caching technologies can easily be arranged (if the server cares) to cache more granularly than is necessarily reflected in the answers. (In fact most of my "cloud" caches I'm currently responsible for do that all the time.) I actually don't deny there's a use case here necessarily, but it may not be all that large, even to Facebook.
- thomasahle 11y ago
  I was thinking of a large graph, where everybody wanted different parts. Then a cache somewhere in the middle could work, even if nobody wanted exactly the same parts. However I guess you could achieve the same by sending many parallel requests.

> No, you use the query in querystring. Ok, but doing that straight on top of HTTP, will only cache queries that are exactly equal to previous ones. Not queries that are a subset of previous queries.

pbhjpbhj 11y ago

If the [data returned following a] query is a subset [of data points already returned] why do you need to get it again; if you actually need to re-retrieve it then it being cached is no use unless you dumped it from local cache mistakenly - that shouldn't be an often enough occurrence to need to cache the data. Or did I miss something?

thomasahle 11y ago
I'm thinking about the case where you have a cache between you and the server, shared by multiple users. I imagine this is useful at facebook, for example for loading parts of public peoples pages, etc. You are right, that if the data is only used by you, you can just have an advanced cache in the client, sorting it out for you.

jerf 11y ago

I think you have to be careful not to be too cavalier with the word "cache" there. While REST is sort of vaguely concerned with the ability to cache in the general sense, in real life we have to be specific about what is doing the caching. This is the sort of dynamic query you'd normally tell intervening proxies not to cache anyhow, so now we can reduce our concerns to the client and the server specifically. On the client, if it asked for a big chunk of the graph and now need to operate on a smaller on, I'd suggest that if the client does not want to incur another round trip, it would be incumbent on the client not to ask another question. (This is further backed up by a consistency concern; if I ask again, I may get a different answer because it has actually changed in the meantime. You may be better off with your code not even looking at the changes.) On the server, caching technologies can easily be arranged (if the server cares) to cache more granularly than is necessarily reflected in the answers. (In fact most of my "cloud" caches I'm currently responsible for do that all the time.) I actually don't deny there's a use case here necessarily, but it may not be all that large, even to Facebook.

thomasahle 11y ago
I was thinking of a large graph, where everybody wanted different parts. Then a cache somewhere in the middle could work, even if nobody wanted exactly the same parts. However I guess you could achieve the same by sending many parallel requests.