On 09/17/2013 11:24 AM, Brad Jorsch (Anomie) wrote:
On Tue, Sep 17, 2013 at 12:27 PM, Gabriel Wicke gwicke@wikimedia.org wrote:
An end point that wants to be cacheable should only use one query parameter, which might well be a path. Hypothetical examples:
http://wiki.org/wiki/Foo?r=latest/html http://wiki.org/wiki/Foo?r=123456/wikitext
So now you're cramming multiple parameters, ordered, into one parameter? Why not go all the way and do http://wiki.org/wiki/123456/wikitext/Foo then?
I consider the article to be the main resource we are interested in, with a revision and then a specific part (format) of that revision as a sub-resource. As our titles can contain slashes we need to delimit the main resource from the sub-resource part. A single query parameter that specifies the sub-resource path achieves that.
What is the actual benefit we're trying to get here? All I've gotten so far along those lines is "improve cacheability", but it doesn't seem to have been established whether caching even needs improving in this area.
A heavily-used content API will perform better and use less resources when it is cacheable. This will become more important over time, so I believe it is worth spending a small amount of effort on now.
Gabriel