Having come this far, it seemed churlish not to go ahead and implement the proposed fix, so I did. This now works nicely – we issue only the GETs that we actually need.

OK, that is a reasonable position. And it does make a lot of the other issues go away very conveniently.

Also, crucially: it is a fix at the level of the individual resource rather than the component (or even as, at present, the module). So when we have modules with multiple resources, we'll get a nice, fine grain of WSAPI calls.

Ultimately I was convinced we don't need the information about which particular sub-state the function used to generate the path because you can find out if it changed by generating the URL again. All having that would do is save the tiny bit of string manipulation it would take to get the URL at the cost of maintaining more code and module authors having to spell out what their resource-path-making-functions use.

So I'm satisfied the API contains enough info for our later optimising purposes.

A mechanism to force a refresh explicitly will still need to be, well, explicit, even if we have that information so I consider it an orthogonal question. Though related.

Yes, we can handle this at lower levels. But I think it's inelegant to issue HTTP requests that you know a cache is going to handle.

And I am jumpy about just refusing to refresh from the same Okapi URL as last time, because what about when that is what you want to do? "I know this has changed because the bloke jjust sitting next to me added a user; refresh, please."

So I would rather handle it at a higher level if possible.

Heh, just saw your more recent comment when it appeared once I submitted mine. Do you think comparing the output of substitution to that generated on the prior run will suffice?