imageusage/globalusage are the best candidates for a merge, we use them in a fully identical way. Not so sure about filerepoinfo, which is fired once per page (not once per image) and is always the same for a given wiki, so every client would only request it once per cache lifetime, and it would never be a Varnish miss. Adding it to every single per-image API request would just bloat the amount of data that has to be transferred, without any significant gain. But as Ori says, we might want to test those assumptions instead of just making them - we should consider how much effort it takes to set up multiple versions (everything separate, imageusage+globalusage merged, imageusage+globalusage+filerepoinfo merged, all merged) and compare them. (Writing the code for it should be pretty simple since the current response parsing code would keep working; not so sure about the deployment/measurement parts.)

Yes, if every component of an API call can be cached in Varnish, then the whole thing can be cached as well.

It would, although I wouldn't be absolutely sure of MediaViewer always constructing the same request. We pass the query parameters to mw.Api (and eventually $.ajax) in a JS object literal, which has no well-defined ordering, and Chrome for example is known to iterate object keys differently from other browsers. Although I think that only happens if you have numeric keys, so yeah, the URL will probably be stable.

 

2-ish, yes. (There is still the users request, which is cross-wiki and would be very hard to merge because of that, but we generate gendered messages (or message; actually there is just one at the moment) with all possible genders and only do an API request for the gender if there is a difference. Only about 10% of languages make use of gender, and most of them are smaller ones (ru and pl are the largest), so the amount of users API requests should be negligible.)